VR-Forces
Users Guide
Users Guide
Copyright © 2017 VT MAK
All rights Reserved. Printed in the United States.
Under copyright laws, no part of this document may be copied or reproduced in any form without prior written consent of VT MAK.
VR-Exchange™, VR-TheWorld™, VR-Vantage™, DI-Guy™, and DI-Guy Scenario™ are trademarks of VT MAK. MÄK Technologies®, VR-Forces®, RTIspy®, B-HAVE®, and VR-Link® are registered trademarks of VT MAK.
Terrain Profiles are based in part on the work of the Qwt project (http://qwt.source- forge.net).
All other trademarks are owned by their respective companies.
For third-party license information, please see “Third Party Licenses,” on page lviii.
VT MAK
150 Cambridge Park Drive, 3rd Floor Cambridge, MA 02140 USA
Voice: 617-876-8085
Fax: 617-876-9208
Revision VRF-4.5-1-170217
How This Manual is Organized ............................................................. xlvii
VR-Forces Documentation................................................................. liii
libXML and libICONV ..................................................................... lix Lua..................................................................................................... lix Freefont OpenType Font Set.............................................................. lix NVIDIA.............................................................................................. lx
Third-Party Licenses for VR-Vantage Applications.............................. lx
Section I Introduction, Installation, and Startup
Chapter 1. Introduction to VR-Forces
Chapter 2. Installing VR-Forces
Chapter 3. VR-Forces Application Concepts
Chapter 5. Command-line Options
Command-line Options for vrfLauncher 5-14
Using the -- Command-line Argument 5-15
Chapter 6. Optimizing Performance
Chapter 7. Creating and Running Scenarios
Chapter 9. Target Detection and Combat Features
Chapter 10. Indirect Fire, Ballistic Missiles, and Munition Detonations
Chapter 11. Setting Environment Conditions
Chapter 13. Using a Communications Effects Server
Chapter 14. Example Entity-Level Scenarios
Section III Simulation Objects
Chapter 15. Introduction to Simulation Objects
Chapter 16. Creating and Placing Objects
Chapter 18. Viewing Information about Objects
Chapter 19. Creating Simulation Objects
Chapter 20. Generating Traffic (Pattern of Life)
Chapter 21. Crowds and Multiple Simulation Objects
Chapter 22. Entity-Level Unit Modeling
Chapter 23. How Aggregate-Level Modeling Works
Chapter 24. Creating and Controlling Units
Chapter 27. Movement Tasks for Entity-Level Scenarios
Chapter 28. Engagement Tasks for Entity-Level Scenarios
Chapter 29. Human and Crowd Tasks
Chapter 30. Embarkation, Wait, Radio, and Other Tasks
Chapter 31. Tasks for Aggregate-Level Scenarios
Chapter 32. Creating Scripted Tasks and Sets
Location3D 33-18
Vector3D 33-18
VectorOffset3D 33-20
VectorGeoc3D 33-20
Chapter 34. Setting the State of Simulation Objects
VI.1. Introduction to Plans 34-1
Chapter 37. Introduction to Tactical Graphics
Chapter 39. Creating and Editing Tactical Graphics
Chapter 40. Setting the State of Tactical Graphics
Section VIII Visual and Audio Effects
Chapter 42. Displaying Tactical Information and Effects
Section IX The Observer and Viewing Scenarios
Chapter 48. The Observer and Observer Modes
Chapter 49. Moving the Observer
Chapter 50. Attaching the Observer to Objects
Chapter 51. Inset Views, Sensor FOVs, and HUDs
Chapter 52. Introduction to Terrain Usage in VR-Forces
Chapter 53. Displaying Terrain Information
Chapter 54. Using Terrain Profiles
Chapter 55. Composing Terrains
Chapter 56. Paged and Streaming Terrains
Chapter 57. Editing Earth Files
Chapter 58. Generating Navigation Data
Chapter 60. Processing MetaFlight Files
Chapter 61. Terrain Performance and Configuration
Chapter 62. Configuring Feature Data
Section XI Creating and Editing Simulation Models
Chapter 64. The Simulation Object Editor and SMSs
Chapter 65. Editing Simulation Object Models
Chapter 66. Editing Units for Entity-Level Scenarios
Chapter 67. Editing Aggregate-Level Objects
Chapter 68. Adding DI-Guy Models to VR-Forces
Chapter 69. The Object Parameter Database
Chapter 70. Using the OPD Editor
Chapter 71. Configuring Sensors
Chapter 72. Configuring Weapon Systems and Munition Damage
Chapter 73. Configuring Movement Systems
Chapter 74. Configuring Emitters and Radios
Chapter 75. Configuring Joystick and Keyboard Controls
Chapter 76. Attaching Components to Remote Entities
76.1. Attaching VR-Forces Components to Remote Entities 76-2
Section XII Configuring the Graphical User Interface
Chapter 77. Display Engine and Window Management
Chapter 78. GUI Controls, Layouts, and Behaviors
Chapter 79. Configuring Toolbars, Dialog Boxes, and Menus
Chapter 80. Creating and Editing Key Mappings
Section XIIIConfiguring Visual Models in the Visual Models Editor
Introduction to Object Modeling 80-2
Chapter 81. Model and Element Definitions
81.2.6. Editing a Schema Parameter 81-8
Chapter 82. Mapping Models and Effects
Chapter 83. 2D Icons, Cockpits, Wakes and other Visual Models
Chapter 84. Configuring Emitter Volumes
Chapter 85. The WRM Specification (DIS Notes)
A.2.1. Using Environment Variables in an MTL File ...................... A-3 A.2.2. Specifying Lists of Lists ......................................................... A-4 A.2.3. Using Conditional Statements .............................................. A-4
B.1. The vrfSim.mtl Configuration File ................................................... B-2
C.1. The Structure of a Simulation Object Parameter ............................. C-2 C.2. The Parameter Type Hierarchy ....................................................... C-3 C.2.1. Vrf Base Object Parameters .................................................. C-3 C.2.2. Vrf Object Parameters .......................................................... C-7 C.2.3. Moving Object Parameters ................................................... C-8
C.2.4. Parameter Types for Entity Platforms ................................... C-8 C.3. Simulation Object Parameters ......................................................... C-8 C.4. Object Type Enumerations .............................................................. C-9 C.4.1. Object Super-type ................................................................. C-9 C.4.2. AggregateKind ...................................................................... C-9 C.4.3. ObjectKind ......................................................................... C-10 C.4.4. Unit Category ..................................................................... C-10 C.4.5. Unit Specific ....................................................................... C-11 C.4.6. Point Object Category ........................................................ C-12 C.4.7. Linear Object Category ....................................................... C-12 C.4.8. Areal Object Category ........................................................ C-12 C.4.9. Interaction .......................................................................... C-12
Appendix D. Systems and System Usage
D.1. VR-Forces Systems ......................................................................... D-2
VR-Forces Quick Reference Card
This manual is written for persons who will install VR-Forces® or use the VR-Forces application. The manual assumes that you are familiar with your operating system and that you know how to work in your computer’s graphical window environment.
Please see release documentation for information about changes and updates to VR- Forces since this manual went to press.
The chapters are organized as follows:
Section I, “Introduction, Installation, and Startup”
Chapter 1, Introduction to VR-Forces, briefly describes VR-Forces and its features.
Chapter 2, Installing VR-Forces, explains how to install VR-Forces, set up license management, and localize the GUI.
Chapter 3, VR-Forces Application Concepts, provides the conceptual background for the simulation process. It will help put some of the discussion in this manual into context.
Chapter 4, Starting VR-Forces describes how to start VR-Forces, load terrain databases, and configure HLA time management.
Chapter 5, Command-line Options, describes the command-line options for vrfGui (the front-end) and vrfSim (the back-end or simulation engine).
Chapter 6, Optimizing Performance describes how to monitor VR-Forces’s performance in the Frame Rate Monitor and how to configure VR-Forces to improve performance.
Chapter 7, Creating and Running Scenarios, explains how to create and run scenarios, how to create batch scenarios, and how to checkpoint scenarios.
Chapter 8, Scenario Events explains how to create and run scenario events.
Chapter 9, Target Detection and Combat Features, describes spot reports, laser targeting, entity hostility, and how entities take damage.
Chapter 10, Indirect Fire, Ballistic Missiles, and Munition Detonations, explains how to configure and call in indirect fire.
Chapter 11, Setting Environment Conditions, describes how to manipulate the date, time of day, and weather conditions.
Chapter 12, Scenario Files describes the files used to define a scenario and how to edit them.
Chapter 13, Using a Communications Effects Server explains how to configure VR-Forces to work with external communications effects servers, such as QualNet.
Chapter 14, Example Entity-Level Scenarios walks you through the process of creating two of the sample scenarios provided with VR-Forces.
Section III, “Simulation Objects”
Chapter 15, Introduction to Simulation Objects contains conceptual details about simulation objects.
Chapter 16, Creating and Placing Objects, explains describes the common proce- dures for creating simulation objects, tactical graphics, and props.
Chapter 17, Selecting Objects describes procedures common to simulation objects, control objects, and tactical graphics.
Chapter 18, Viewing Information about Objects explains how simulation objects are displayed, how you can change the display of simulation objects, and how you can display information about simulation objects.
Chapter 19, Creating Simulation Objects, explains the fine points of creating simulation objects, with a particular emphasis on simulation objects in entity- level scenarios. It also covers embarkation and collision avoidance.
Chapter 20, Generating Traffic (Pattern of Life) explains how to use the Spawn Pattern Manager to create pattern of life traffic.
Chapter 21, Crowds and Multiple Simulation Objects explains how to create multiple simulation objects at one time and how to create and task pedestrian crowds.
Chapter 22, Entity-Level Unit Modeling, describes working with units in entity- level scenarios.
Chapter 23, How Aggregate-Level Modeling Works, describes the aggregate-level warfare model.
Chapter 24, Creating and Controlling Units, explains how to create and edit units.
– Chapter 25, Displaying Units describes how to view units.
Chapter 26, Assigning Tasks, provides general information about assigning tasks and creating behavior sets.
Chapter 27, Movement Tasks for Entity-Level Scenarios, describes movement tasks for simulation objects in entity-level scenarios.
Chapter 28, Engagement Tasks for Entity-Level Scenarios, describes combat-related tasks for simulation objects in entity-level scenarios.
Chapter 29, Human and Crowd Tasks, describes tasks for humans and crowds in entity-level scenarios.
Chapter 30, Embarkation, Wait, Radio, and Other Tasks, describes the tasks provided with VR-Forces that apply to simulation objects in entity-level scenarios.
Chapter 31, Tasks for Aggregate-Level Scenarios, describes the tasks that apply to simulation objects in aggregate-level scenarios.
Chapter 32, Creating Scripted Tasks and Sets, introduces scripts and explains how to create them. It does not cover how to write scripts.
Chapter 33, Writing Scripts, introduces the Lua script API for VR-Forces and explains how to write scripts
Chapter 34, Setting the State of Simulation Objects, describes how to change the state of simulation objects using set data requests.
Chapter 35, Plan Concepts describes plans and plan components.
Chapter 36, Writing Plans explains how to write plans for simulation objects and how to write global plans.
Section VII, “Tactical Graphics”
Chapter 37, Introduction to Tactical Graphics is a brief introduction to tactical graphics.
Chapter 38, Overlays describes the creation and use of overlays.
Chapter 39, Creating and Editing Tactical Graphics describes how to create tactical graphics other than points, lines, and areas, and how to edit tactical graphics.
Chapter 40, Setting the State of Tactical Graphics describes set data requests that apply to tactical graphics.
Chapter 41, Remote Graphics explains how to enable display of graphics gener- ated by remote applications.
Section VIII, “Visual and Audio Effects”
Chapter 42, Displaying Tactical Information and Effects describes how to display a variety of simulation object effects such as trailing effects, shadows, and sensor volumes.
Chapter 43, Lighting Effects describes the lighting effects supported by VR- Forces and how to manage them.
Chapter 44, Marine Effects describes water related effects, such as displaying rain splash and water spray. It also covers wake effects and entity buoyancy.
Chapter 45, Using Sensors explains how to enable and configure infrared and night vision goggle sensor views.
Chapter 46, Intervisibility explains how to determine if simulation objects can see other simulation objects or areas of the terrain.
Chapter 47, Sound Effects explains how to enable and configure sound effects for entities.
Section IX, “The Observer and Viewing Scenarios”
Chapter 48, The Observer and Observer Modes explains what an observer is and the different ways observers can be configured.
Chapter 49, Moving the Observer explains how to navigate the 3D and 2D views by moving the observer.
Chapter 50, Attaching the Observer to Objects explains how to attach the observer to simulation objects. This is an alternative to manually moving the observer through the terrain.
Chapter 51, Inset Views, Sensor FOVs, and HUDs describes special secondary windows – inset views, sensor fields of view, and instrument panels, and HUDs.
Chapter 52, Introduction to Terrain Usage in VR-Forces provides conceptual back- ground for terrain use in VR-Forces.
Chapter 53, Displaying Terrain Information describes ways to change how terrain is displayed. These options provide different types of information about the terrain.
Chapter 54, Using Terrain Profiles explains how to display and configure terrain profiles.
Chapter 55, Composing Terrains explains how to build terrain databases by importing elevation data, imagery, and feature data.
Chapter 56, Paged and Streaming Terrains explains how to use terrain servers for paged and streaming terrains. It also provides information about preparing paged terrains for use in VR-Forces.
Chapter 57, Editing Earth Files explains the syntax of earth files so that you can customize them for viewing streaming terrain from terrain servers.
Chapter 58, Generating Navigation Data explains how to generate navigation data for advanced navigation by humans and ground entities.
Chapter 59, Dynamic Terrain explains how to use the dynamic terrain capability in VR-Forces.
Chapter 60, Processing MetaFlight Files explains how to preprocess MetaFlight files so that VR-Forces can load them.
Chapter 61, Terrain Performance and Configuration covers miscellaneous issues that affect terrain performance and function.
Chapter 62, Configuring Feature Data explains how to create configuration files for feature data whose attributes use different values than the ones that are preconfigured by VR-Forces.
Chapter 63, Terrain Tutorials provides step-by-step instructions for creating and saving a terrain database.
Section XI, “Creating and Editing Simulation Models”
Chapter 64, The Simulation Object Editor and SMSs explains simulation model sets (SMSs) and how to create them in the Simulation Object Editor.
Chapter 65, Editing Simulation Object Models explains how to use the Simula- tion Object Editor to edit simulation object parameters, systems, and models. It covers procedures that are common to entity-level and aggregate-level SMSs and specific to individual entities.
Chapter 66, Editing Units for Entity-Level Scenarios explains how to configure unit composition and formations in the Simulation Object Editor. This chapter applies to units in entity-level scenarios.
Chapter 67, Editing Aggregate-Level Objects explains how to configure aggregates for aggregate-level scenarios in the Simulation Object Editor.
Chapter 68, Adding DI-Guy Models to VR-Forces explains how to configure new DI-Guy characters.
Chapter 69, The Object Parameter Database describes the object parameter data- base, which contains parameters for simulation objects and control objects, and how to edit it.
Chapter 70, Using the OPD Editor explains how to use the OPD Editor to edit entity and system parameters. The OPD Editor lets you edit all simulation object parameters, while the Simulation Object Editor only lets you edit some parameters.
Chapter 71, Configuring Sensors explains how to configure sensors and sensor signatures.
Chapter 72, Configuring Weapon Systems and Munition Damage explains how to configure the munition selection tables, damage tables, and hit probability tables.
Chapter 73, Configuring Movement Systems explains how to configure obstacle avoidance, embarkation, and formations.
Chapter 74, Configuring Emitters and Radios explains how to configure emitters and radios.
Chapter 75, Configuring Joystick and Keyboard Controls explains how to configure joysticks and keyboard keys to control entity movement.
Chapter 76, Attaching Components to Remote Entities explains how to configure sensors and sensor signatures.
Section XII, “Configuring the Graphical User Interface” GUI use and customiza- tion.
Chapter 77, Display Engine and Window Management explains how to configure windows and channels and how to save and load display configurations.
Chapter 78, GUI Controls, Layouts, and Behaviors explains how to manage tool- bars and other aspects of the VR-Forces GUI.
Chapter 79, Configuring Toolbars, Dialog Boxes, and Menus explains how to configure the menus, toolbars, and dialog box pages that get displayed.
Chapter 80, Creating and Editing Key Mappings explains how to edit key mappings and create new key mappings.
Section XIII, “Configuring Visual Models in the Visual Models Editor”
Chapter 81, Model and Element Definitions explains how to create and edit model schemas, model definitions, and element definitions.
Chapter 82, Mapping Models and Effects explains how to map entity enumera- tions to the models configured in VR-Forces.
Chapter 83, 2D Icons, Cockpits, Wakes and other Visual Models explains how to configure some specific visual models, including 2D Icons, cockpits, and SpeedTree trees.
Chapter 84, Configuring Emitter Volumes explains how to configure color, radius, and segment size for emitter volumes.
Chapter 85, The WRM Specification (DIS Notes) explains the WRM specification for 3D modeling.
Section XIV, “Appendixes”.
Appendix A, MTL Syntax explains the syntax of configuration files provided with VR-Forces.
Appendix B, The vrfSim.mtl Configuration File describes the parameters in
vrfSim.mtl.
Appendix C, Object Parameters describes the high level parameters used in OPD files.
Appendix D, Systems and System Usage lists all the systems provided with VR- Forces and provides information about them, including which entities use them.
MÄK Products Glossary defines terms common to DIS, HLA, and MAK products.
VR-Forces Quick Reference Card lists command line options, keyboard shortcuts, and navigation and view options.
VR-Forces documentation is provided as manuals in PDF format, online help, and HTML class documentation. The PDF files are in the ./doc directory. The VR-Forces documentation set is as follows:
VR-Forces Users Guide contains all documentation for running VR-Forces, creating and running scenarios, and configuring VR-Forces.
VR-Forces Migration Guide collates API migration information for recent releases.
Online help. The VR-Forces front-end, the OPD Editor, and the Simulation Object Editor have online help accessible from the Help menu.
VR-Forces Developers Guide and API documentation. Class documentation and developers guides in linked HTML pages.
VR-Forces Release Notes.
VR-Forces First Experience Guide. A brief introduction to the most basic features of VR-Forces.
VR-Forces Entity Model Catalog. A catalog of all of the simulation objects and tactical graphics configured in the Simulation Object Editor, with basic parameter details and a screen capture of the 3D model or icon.
VR-Forces is a member of the VT MAK line of software products designed to stream- line the process of developing and using networked simulated environments. The VT MAK product line includes the following:
VR-Link® Network Toolkit. VR-Link is an object-oriented library of C++ func- tions and definitions that implement the High Level Architecture (HLA) and the Distributed Interactive Simulation (DIS) protocol. VR-Link has built-in support for the RPR FOM and allows you to map to other FOMs. This library minimizes the time and effort required to build and maintain new HLA or DIS-compliant applications, and to integrate such compliance into existing applications.
VR-Link includes a set of sample debugging applications and their source code. The source code serves as an example of how to use the VR-Link Toolkit to write applications. The executables provide valuable debugging services such as gener- ating a predictable stream of HLA or DIS messages, and displaying the contents of messages transmitted on the network.
MAK RTI. An RTI (Run-Time Infrastructure) is required to run applications using the High Level Architecture (HLA). The MAK RTI is optimized for high perfor- mance. It has an API, RTIspy®, that allows you to extend the RTI using plug-in modules. It also has a graphical user interface (the RTI Assistant) that helps users with configuration tasks and managing federates and federations.
Preface — MAK Products
VR-Forces®. VR-Forces is a computer generated forces application and toolkit. It provides an application with a GUI, that gives you a 2D and 3D views of a simu- lated environment.
You can create and view entities, aggregate them into hierarchical units, assign tasks, set state parameters, and create plans that have tasks, set statements, and conditional statements. You can simulate using entity-level modeling, which focuses on the actions of individual people and vehicles, and aggregate-level modeling, which focuses on the interaction of large hierarchical units.
VR-Forces also functions as a plan view display for viewing remote simulation objects taking part in an exercise. Using the toolkit, you can extend the VR-Forces application or create your own application for use with another user interface.
VR-Vantage™. VR-Vantage is a line of products designed to meet your simulation visualization needs. It includes three end-user applications (VR-Vantage Stealth, VR-Vantage PVD, and VR-Vantage IG) and the VR-Vantage Toolkit.
VR-Vantage Stealth displays a realistic, 3D view of your virtual world, a 2D plan view, and an exaggerated reality (XR) view. Together these views provide both situational awareness and the big picture of the simulated world. You can move your viewpoint to any location in the 3D world and can attach it to simulation objects so that it moves as they do.
VR-Vantage IG is a configurable desktop image generator (IG) for out the window (OTW) scenes and remote camera views. It has most of the features of the Stealth, but is optimized for its IG function.
VR-Vantage PVD provides a 2D plan view display. It gives you the big picture of the simulated world.
SensorFX. SensorFX is an enhanced version of VR-Vantage that uses physics based sensors to view terrain and simulation object models that have been mate- rially classified. It is built in partnership with JRM Technologies.
The VR-Vantage Toolkit is a 3D visual application development toolkit. Use it to customize or extend MAK’s VR-Vantage applications, or to integrate VR- Vantage capabilities into your custom applications. VR-Vantage is built on top of OpenSceneGraph (OSG). The toolkit includes the OSG version used to build VR-Vantage.
MAK Data Logger. The Data Logger, also called the Logger, can record HLA and DIS exercises and play them back for after-action review. You can play a recorded file at speeds above or below normal and can quickly jump to areas of interest. The Logger has a GUI and a text interface. The Logger API allows you to extend the Logger using plug-in modules or embed the Logger into your own application. The Logger editing features let you merge, trim, and offset Logger recordings.
VR-Exchange™. VR-Exchange allows simulations that use incompatible commu- nications protocols to interoperate. For example, within the HLA world, using VR- Exchange, federations using the HLA RPR FOM 1.0 can interoperate with simula- tions using RPR FOM 2.0, or federations using different RTIs can interoperate. VR-Exchange supports HLA, TENA, and DIS translation.
VR-TheWorld™ Server. VR-TheWorld Server is a simple, yet powerful, web- based streaming terrain server, developed in conjunction with Pelican Mapping. Delivered with a global base map, you can also easily populate it with your own custom source data through a web-based interface. The server can be deployed on private, classified networks to provide streaming terrain data to a variety of simula- tion and visualization applications behind your firewall.
DI-Guy™. The DI-Guy product line is a set of software tools for real-time human visualization, simulation, and artificial intelligence. Every DI-Guy software offering comes with thousands of ready-to-use characters, appearances, and motions. DI- Guy enables the easy creation of crowds and individuals who are terrain aware, autonomous, and react intelligently to ongoing events. Save time, money and create outstanding simulations with DI-Guy. The DI-Guy product line includes the following products:
The DI-Guy SDK. Embed the DI-Guy library in your real-time application and populate your world with lifelike human characters.
DI-Guy Scenario™. Author and visualize human performances in a rich, user- friendly graphical environment. Use DI-Guy Scenario as an end visualization application or save scenarios and load them into your DI-Guy SDK enabled application.
ECOSim. Enhanced Company Operations Simulation (ECOSim) is a company-level training simulation that teaches leaders how best to deploy troops, UAVs, convoys, and other assets. ECOSim focuses on ease-of-use, rapid scenario generation, runtime operator control, and realistic and reactive human simulation.
DI-Guy AI. Generate crowds of autonomous characters to quickly populate your worlds with hundreds and thousands of terrain-aware, collision avoiding DI- Guys. Used as a module on top of DI-Guy Scenario and DI-Guy SDK.
Expressive Faces Module. Enable DI-Guy characters to have faces that display emotion, eyes that look in directions and blink, and lips that sync to sound files.
DI-Guy Motion Editor. Create or customize motions to your particular needs in an easy-to-use graphical application.
RadarFX. RadarFX is a client-server application that simulates synthetic-aperture radar (SAR). The server application, which is based on VR-Vantage and SensorFX, loads a terrain database and, optionally, connects to simulations. A client applica- tion requests SAR images from the server. RadarFX includes a sample client appli- cation.
VR-Engage. VR-Engage is a multi-role virtual simulator that lets users play the role of a first person human character, a ground vehicle driver, gunner or commander, or the pilot of a fixed wing aircraft or helicopter. It incorporates the VR-Force simulation engine and the VR-Vantage graphics rendering capabilities.
Preface — How to Contact Us
WebLVC Server. WebLVC Server implements the server side of the WebLVC protocol so that web-based simulation federates can participate in a distributed simulation. It is part of the WebLVC Suite, which includes the server and several sample applications that work with VR-Forces and VR-Vantage.
For VR-Forces technical support, information about upgrades, and information about other MAK products, you can contact us in the following ways:
Call or fax us at: Voice: Fax:
617-876-8085 (extension 3 for support)
617-876-9208
Sales and upgrade information: Technical support:
MAK web site home page: www.mak.com
License key requests: www.mak.com/support/licenses/ get-licenses
Product version and platform information: www.mak.com/support/product-versions For the free, unlicensed MAK RTI: www.mak.com/support/resources/bonus-
material
MAK Community Forum: www.mak.com/connect/forum
Send postal correspondence to: VT MAK
150 Cambridge Park Drive, 3rd Floor Cambridge, MA, USA 02140
When requesting support, please tell us the product you are using, the version, and the platform on which you are running.
Preface — Document Conventions
This manual uses the following typographic conventions: Monospaced Indicates commands or values you enter. Monospaced Bold Indicates a key on the keyboard.
Monospaced Italic Indicates command variables that you replace with appropriate values.
Blue text A hypertext link to another location in this manual or another manual in the documentation set.
{ } Indicates required arguments.
[ ] Indicates optional arguments.
| Separates options in a command where only one option may be chosen at a time.
( | ) In command syntax, indicates equivalent alternatives for a command-line option, for example, (-h | --help).
/ Indicates a directory. Since MAK products run on both Linux and Windows PC platforms, we use the / (slash) for generic discus- sions of pathnames. If you are running on a PC, substitute a \ (backslash) when you type pathnames.
Italic Indicates a file name, pathname, or a class name.
sans Serif Indicates a parameter or argument.
Indicates a one-step procedure.
Menu Option Indicates a menu choice. For example, an instruction to select the Save option from the File menu appears as:
Choose File Save.
Click the icon to run a tutorial video in the default browser.
!
!
i Indicates supplemental or clarifying information.
Indicates additional information that you must observe to ensure the success of a procedure or other task.
Indicates that a section is valid only for entity-level scenarios.
Indicates that a section is valid only for aggregate-level scenarios.
Directory names are preceded with dot and slash characters that show their position with respect to the VR-Forces home directory. For example, the directory vrforces4.5/doc appears in the text as ./doc.
An instruction to click the mouse button, refers to clicking the primary mouse button, usually the left button for right-handed mice and the right button for left-handed mice. The context-sensitive menu, also called a popup menu or right-click menu, refers to the menu displayed when you click the secondary mouse button, usually the right button on right-handed mice and the left button on left-handed mice.
MAK software products may use code from third parties. This section contains the license documentation required by these third parties.
Boost Software License - Version 1.0 - August 17th, 2003
Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software and accompanying documentation covered by this license (the “Software”) to use, reproduce, display, distribute, execute, and transmit the Software, and to prepare derivative works of the Software, and to permit third-parties to whom the Software is furnished to do so, all subject to the following:
The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software, unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEAL- INGS IN THE SOFTWARE.
Preface — Third Party Licenses
VR-Link and all MAK software that uses VR-Link, links in libXML and libICONV. On some platforms the compiled libraries and header files are distributed with MAK Products. MAK has made no modifications to these libraries. For more information about these libraries please see the following web sites:
The LGPL license is available at: http://www.gnu.org/licenses/lgpl.html.
Information about IconV is at: http://www.gnu.org/software/libiconv/.
Information about LibXML is at: http://xmlsoft.org/.
Some MAK products use the Lua programming language (www.lua.org). Its license is as follows:
Copyright © 1994–2012 Lua.org, PUC-Rio.
Permission is hereby granted, free of charge, to any person obtaining a copy of this soft- ware and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEAL- INGS IN THE SOFTWARE.
The HDR implementation uses the HDR NVIDIA gameworks SDK example that has the following copyright notice:
Multiple Files in folder: es3aep-kepler\HDR/ SDK Version: v2.11
Email: gameworks@nvidia.com Site: http://developer.nvidia.com/
Copyright (c) 2014-2015, NVIDIA CORPORATION. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Neither the name of NVIDIA CORPORATION nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
VR-Vantage applications use a variety of third-party libraries. Developers who want to use these libraries may be required to purchase developer’s licenses. Please see section
in VR-Forces Front-End Developers Guide for details.
Introduction, Installation, and Startup
VR-Forces is a computer generated forces (CGF) application and toolkit. VR-Forces is implemented using separate front-end (graphical user interface) and back-end (simula- tion engine) applications that allow tremendous flexibility for managing your simula- tion needs.
VR-Forces Users Guide
Section I - Introduction, Installation, and Startup
I-1
Introduction, Installation, and Startup
Section I - Introduction, Installation, and Startup
I-2 VT MAK
1. Introduction to VR- Forces
This chapter provides a high-level description of VR-Forces features.
Entity-Level and Aggregate-Level Simulation 1-5
Realistic Display of Vehicles and Terrain (3D View) 1-7
Simulation Object Types Supported 1-8
Scripted Tasks and Set Data Requests 1-11
Terrain Agility and Composability 1-12
Crowd Behaviors and Pattern of Life 1-12
Flexible, Intuitive Graphical User Interface 1-13
Special Effects and Simulation Object Information Visualization 1-14
Accurate Vehicle Positioning 1-15
Support for External Communications Servers 1-17
Introduction to VR-Forces
Third-Party Software and Content 1-19
3D Models, Terrain, and Graphical Content 1-21
Distributed Simulation Standards Supported 1-22
VR-Forces is a computer generated forces (CGF) application and toolkit. VR-Forces is implemented using separate front-end (graphical user interface) and back-end (simula- tion engine) applications that allow tremendous flexibility for managing your simula- tion needs. (For information about how this works, please see “The VR-Forces Program,” on page 3-2.)
VR-Forces provides 3D and 2D views of your simulated world, integrated into one graphical user interface (GUI). The 2D view provides you with insights into a simu- lated battle by overlaying simulation objects and information onto 2D views of tactical, strategic, and visual databases. The 2D view answers typical questions about the place- ment of forces and how the terrain might affect the engagement more easily than do three-dimensional displays. It is ideally suited for viewing simulations over large areas of open terrain.
The 3D view provides three-dimensional, perspective views of the terrain and entity models. It is ideal for scenarios that require situational awareness, simulation debug- ging, or after action review. It is particularly useful for placing entities with precise loca- tion and orientation and for working in terrains in which entities can be at multiple altitudes at a given X, Y coordinate, such as urban terrains.
The 3D view includes exaggerated reality (XR) features. Model scaling and additional model sets help to provide a common operational picture of the simulated world.
VR-Forces is compatible with the Distributed Interactive Simulation (DIS) and High Level Architecture (HLA) simulation standards. It supports multiple database formats and terrain servers. VR-Forces is interoperable with other MAK products, such as VR- Vantage Stealth and MAK Data Logger.
The VR-Forces front-end is built with the VR-Vantage Toolkit. The VR-Vantage Toolkit is based on OpenSceneGraph1, so you can leverage value-added plug-ins built by the OSG community and MÄK partners.
“OpenSceneGraph is an Open Source, cross-platform graphics toolkit for the development of high- performance graphics applications such as flight simulators, games, virtual reality and scientific visu- alization. It is based on the concept of a SceneGraph, providing an object-oriented framework on top of OpenGL.” (http://www.openscenegraph.org/projects/osg/wiki/About/Introduction)
Table 1-1 lists VR-Forces visual features supported in the 3D and 2D views for entity- level scenarios.
Feature | 3D | 2D |
Terrain agility and composability | X | X |
Attach modes | X | X |
Observer movement modes | ||
Observer frame | X | X |
Level observer frame | X | |
Laptop | X | X |
2D level observer frame | X | |
Model sets | ||
3D models | X | X (top view) |
3D colorized models | X | X (top view) |
2D icons | X | X |
Other Features | ||
Audio | X | X |
Cockpit displays | X | |
Communications lines | X | X |
Detonation and muzzle flashes | X | |
DI-Guy characters | X | |
Display units configuration | X | X |
Dynamic ocean | X | |
Dynamic terrain | X | X |
Emitter volumes | X | X |
Entity labels | Text panels | Configurable symbol decorations |
Environment effects | X | |
Extruded tactical graphics | X | |
Fire and detonation lines | X | X |
Forward+ lighting | X | |
High dynamic range lighting | X | |
Intervisibility | X | X |
Paged terrain | X | X |
Table 1-1: VR-Forces features by projection (Sheet 2 of 2)
Feature | 3D | 2D |
Range rings | X | X |
Remote draw API | X | X (2D graphics only) |
Sea spray effects | X | |
Sensors | X | X (Stealth only) |
Sensor contact lines | X | X |
Shader-based effects maps | X | |
Shadows | X | |
SpeedTree trees | X | |
Streaming buoys and beacons | X | X |
Streaming terrain | X | X |
Tactical graphics | X | X |
Tactical smoke | X | |
Task visualization | X | X |
Terrain profiles | X | X |
Tracers | X | |
Track histories | X | X |
Trailing effects | X | |
View controls | X | X |
Wireframe view | X | X |
Zoom | X | X |
VR-Forces supports two approaches to simulation – entity-level simulation and aggre- gate-level simulation. In entity-level simulations, VR-Forces models individual entities, such as ships, tanks, automobiles, airplanes, and people. Interaction, and for military simulations, warfare, takes place between individual entities. You can aggregate entities into hierarchical units, but for the most part they are still modeled as individuals.
Aggregate-level simulations do not model individual entity interactions and combat. They are concerned with the high level movement and interaction of large numbers of personnel and equipment. Aggregate-level combat is modeled based on the relative strengths and weaknesses of hierarchical units in personnel, equipment, and location, not on the engagement of the individual entities that they represent. Aggregate-level simulations are used for modeling the operational tempo of large area/theater level missions overseen by command staff level officers. This is useful for training staff offi- cers and stimulating Command and Control systems (for example, C2, C4I, C4ISR, and Mission Command systems). (Aggregate-level simulations include some entity models to facilitate certain types of munition attacks. However, they use the same modeling approach as units. They do not behave like the comparable entities in entity- level simulations.)
Most of the information in VR-Forces documentation applies to both types of modeling. The procedures for creating scenarios, adding simulation objects and tactical graphics, assigning tasks and writing plans, and displaying scenario information are almost identical in both types of scenarios.
Therefore, if you want to know how to create a scenario that uses aggregate- level modeling, for example, just follow the procedures in Chapter 7, Creating and Running Scenarios. Or, if you want to learn about assigning tasks in entity-level scenarios, just read Chapter 26, Assigning Tasks.
If a section only applies to entity-level scenarios, it has an entity icon ( ) in the margin. If a section only applies to aggregate-level scenarios, it has a unit icon 
) in the margin.
For conceptual information about the differences between entity-level modeling and aggregate-level modeling, please see the following sections:
“Entity-Level Modeling and Aggregate-Level Modeling,” on page 15-10.
Section IV, “Modeling Units”.
Chapter 23, How Aggregate-Level Modeling Works.
For information specific to the different types of modeling, please see the following sections:
Chapter 31, Tasks for Aggregate-Level Scenarios.
Chapter 66, Editing Units for Entity-Level Scenarios.
Chapter 67, Editing Aggregate-Level Objects.
VR-Forces provides a realistic display using terrain and moving-model geometry in the OpenFlight format. It includes many 3D vehicle models, some of which display move- ment of articulated parts, such as turrets and rotors. These models can change to show a damaged or destroyed state. You can provide your own models and map them to object types. For details about terrain, please see Chapter 55, Composing Terrains. For details about models, please see Chapter 82, Mapping Models and Effects.
i Aggregate-level scenarios do not use 3D vehicle models.
VR-Forces lets you create complex scenarios to meet your simulation requirements. You can:
Create and delete simulation objects.
Create, delete, and edit tactical graphics.
Assign a sequence of tasks and set data requests to a simulation object as a plan.
Assign tasks and set data requests independently of plans.
Create global plans that run independently of any simulation object.
Observe the behavior of simulation objects in response to their environment.
Create, save, and load scenarios that consist of:
Terrain database information.
An order of battle.
Tactical graphics.
A plan for each simulation object in the order of battle.
Manage hostility relationships.
Manage spot reports.
Determine line-of-sight between simulation objects.
Aggregate and disaggregate, and expand and collapse units.
Create overlays and add tactical graphics and simulation objects to them.
Schedule scenario events to inject non-simulated input, such as text, video, and graphics to scenario participants.
Apply weather conditions to a particular area of the terrain.
Using VR-Forces, you can interactively add simulation objects to a simulation and you can aggregate them into higher echelon units. Simulation objects provided for entity- level scenarios include:
Ground entities, such as:
M1A2 Tank
T-80 Tank
HMMWV Utility Vehicle
BTR-80 APC
M2A2 Bradley IFV
IEDs
Civilian vehicles, such as automobiles, police cars, and fire engines.
Air entities, such as:
F-16 Falcon
F/A-18 Hornet
A-10 Thunderbolt
VTUAV Cypher
MiG-29 Fulcrum
AH-64 Apache
Civilian aircraft, such as Boeing 747 and Airbus A320.
Surface and subsurface entities, such as:
AAVC7A1 Landing craft
LCAC
Aircraft carrier
Guided missile frigate
Submarine
Sailboats
Cargo ships.
Life forms, such as:
Dismounted infantry
Civilian.
Units, such as platoons and companies.
Aggregate-level scenarios have simulation object types such as:
ADA PLT
Air Attack company
Artillery battery
Engineering company
Ground attack aircraft
Mechanized infantry company
Mortar platoon
Rifle company
Tank company
Destroyer
Submarine.
You can interactively modify aspects of a simulation object’s state, including:
Speed.
On-board stores such as fuel and ammunition.
Location.
Heading.
For more information about changing a simulation object’s state, please see Chapter 34,
Setting the State of Simulation Objects.
You can modify simulation object parameters by editing the object parameter database and other configuration files.
Simulation objects can embark on and disembark from other simulation objects, for example, dismounted infantry can embark on a truck, HMMWVs can embark on an LCAC, and fixed-wing aircraft can land on and take off from aircraft carriers.
To use embarkation in HLA federations, you must use RPR FOM 2.0, draft 17 or later. For information about specifying the correct FOM, please see “Starting VR-Forces,” on page 4-3 and “Specifying the RPR FOM Version,” on page 5-18.
You can create plans for simulation objects that contain tasks, set data requests, condi- tional statements and global commands. You can save plans and edit them.
Conditional statements specify that tasks will be executed only if a specific condition is true or false. Some of the conditions tested are:
Is a simulation object in a specific area?
Is a simulation object destroyed?
Is a simulation object to the left or right of a phase line?
In addition to conditional statements that are checked only once (If statements), VR- Forces supports Triggers, While statements, and Wait Until statements.
Global plans exist independently of any simulation object. They allow you to assign tasks and set data requests to simulation objects and execute other commands. In essence, they allow you to script the sorts of ad hoc actions that a VR-Forces user could take through the GUI. This provides a great amount of flexibility to automatically modify the order of battle and tactical graphics in response to events.
For more information, please see Chapter 36, Writing Plans.
You can assign tasks to simulation objects as part of a plan or independently. The tasks supported in entity-level scenarios include:
Move to an object.
Patrol along a route.
Patrol between two objects.
Follow an entity.
Fire for effect.
Take off and land.
Fly to a heading.
The tasks supported in aggregate-level scenarios include:
Move to an object.
Patrol along a route.
Patrol between two objects.
Construct a minefield (and other combat engineering objects).
Breach an obstacle.
Bomb a location.
Reactive tasks are a special kind of scripted task. They monitor the simulation and get executed only if some special condition is met. You can manage assignment of reactive tasks in the GUI. For more information, please see “Reactive Tasks,” on page 26-12.
Background processes are another special type of scripted task. They run continuously and manage ongoing simulation object activities. There is no user interface for managing them. For more information, please see “Background Processes,” on
page 33-30.
You can organize scripts into groups called Behavior Sets. By assigning Behavior Sets to forces you can control whether or not scripts are available to simulation objects in those forces. For more information, please see “Using Behavior Sets to Manage Scripts,” on page 26-19.
Using VR-Forces, you can interactively create and name tactical graphics, such as:
Points
Phase lines
Lines
Areas
Obstacles.
Simulation objects are aware of some types of tactical graphics and can be assigned tasks such as following a route, or moving between points. VR-Forces can also determine if specified simulation objects are in an area and this information can be used as part of mission planning.
Aggregate-level scenarios support combat engineering objects, which can be areal, point, or linear objects that could impede, damage, or defend a simulation object.
Other types of tactical graphics are for informational and tactical management purposes and do not affect the simulation. For more information, please see Chapter 38, Over- lays.
You can load local terrain data and you can stream data from networked servers using the osgEarth earth file format.
i VR-Forces only supports geocentric terrains in osgEarth earth files.
You can save these composed terrains in the MTF file format. For details, please see Chapter 55, Composing Terrains. For a list of supported file formats, please see “Supported File Formats,” on page 52-2.
VR-Forces supports the following coordinate systems:
UTM
Geocentric
MGRS
Latitude, longitude
Database.
You can overlay raster images, such as CADRG, BMP, and geotiff files on terrain data- bases.
Terrain state can be changed using switch nodes in the terrain models. Terrain changes can be caused by munition damage, user initiated changes, and using entity tasks.
You can quickly create civilian crowds that have inherent behaviors of wandering and fleeing munition detonations. You can assign tasks to crowds, such as gathering around a person or point. For details, please see Chapter 21, Crowds and Multiple Simulation Objects.
You can use the pattern of life feature to generate civilian and vehicular traffic using various spawn patterns to simulate typical background traffic for scenarios. For details, please see Chapter 20, Generating Traffic (Pattern of Life).
VR-Forces’s graphical user interface (GUI) allows you to manipulate VR-Forces from menus, dockable control panels, and the keyboard.
The VR-Forces display includes the following features:
Manipulate the simulation map by zooming and panning.
Select and track simulation objects.
Turn display features on and off.
Display a hierarchical, echelon view of simulation objects and an embarkation view.
Display entity labels that include several types of information.
Display line-of-sight (intervisibility) for simulation objects.
You can hide and display the control panels, keep them docked to the screen, or undock them to make more space available for the display window. The GUI controls can be hidden for full-screen demonstrations.
The GUI follows standard conventions for modern windowing systems. For additional details, please see Appendix 78, GUI Controls, Layouts, and Behaviors. For descriptions of individual windows and dialog boxes, please see online help.
Overlays mimic clear plastic sheets that a planner might use to draw graphics on top of a terrain map. All objects are automatically assigned to overlays. You can add overlays and move objects between overlays. You can hide the display of objects on an overlay. For details, please see “Overlays,” on page 38-1.
Simulation objects understand how to interact with their environment. For example, they can:
Respond appropriately to other simulation objects and tactical graphics, for example, avoiding simulation objects, waiting for orders, and so on.
Respond to detected targets, for example, deciding which of multiple targets to acquire, which weapon to fire, and what ammunition to use.
Follow a route.
Manually control the observer’s position and orientation. (The observer represents the user’s view, or eyepoint, in the simulated world.)
Follow a simulation object, maintaining a consistent positional offset, with a matching heading.
Mimic a vehicle’s position and orientation. You can place the observer inside the vehicle for a driver’s-eye view, or fly outside of it, moving in tandem with the vehicle.
Tether the observer to a simulation object, maintaining a consistent positional offset without changing the observer’s heading.
Automatically track a vehicle’s movement from a fixed viewpoint, as if watching from a control tower.
For more information, please see Chapter 49, Moving the Observer.
VR-Forces includes features that help you understand the interaction between simula- tion objects that add a realistic tone to interactions. These features include:
Fire and detonation lines.
Track histories.
Range rings.
Radio communications lines.
Trailing effects such as footprints, tire tracks, and wakes.
VR-Forces provides dynamic ocean visualization in the Stealth and Out-the-Window observer modes. The ocean shows waves, swells, and spray effects. Surface entities have realistic wakes and buoyancy behavior. Changes to wind speed and direction affect wave action.
VR-Forces supports a variety of lighting effects, including:
Dynamic lighting
High dynamic range lighting
Ocean planar reflection
Lens flare
Crepuscular (sun) rays.
VR-Forces supports several types of shader-based effects texture maps. Shaders are computer programs that simulate the effect of light on the terrain and objects in the simulation. VR-Forces makes extensive use of them for visualization effects.
VR-Forces supports the following types of shader-based effects maps:
Normal, or bump, maps. Normal maps give terrains the appearance of relief, such as a rocky landscape.
Specular maps. Specular maps affect the highlight color of objects.
Ambient occlusion maps. Ambient occlusion maps model areas that do not receive direct light, such as cracks and crevices and shaded areas of terrain and models. These areas are lit only by ambient light.
Reflection maps. Reflection maps affect the reflectivity of surfaces, such as windows. Reflection maps reflect objects in the sky, not the terrain.
Emissive maps. Emissive maps control the emissivity of whatever they are applied to based on the current ambient light values.
Lighting effects are described in Chapter 43, Lighting Effects.
VR-Forces can smooth the trajectories of moving vehicles to compensate for discontin- uous positional data. The ground clamping feature can ensure that all ground entities are placed correctly on the terrain surface. For details, please see “Trajectory Smoothing,” on page 6-16 and “Using Ground Clamping,” on page 19-20.
Batch mode allows you to run a scenario multiple times or run several different scenarios, without direct action through the graphical user interface. This is useful for running unattended testing or to test the results of a scenario under differing condi- tions. You can record the results of batch mode simulations using the MAK Data Logger, for later review. For more information, please see “Running VR-Forces in Batch Mode,” on page 7-36.
Introduction to VR-Forces — The VR-Forces Toolkit
You can control the VR-Forces observer remotely through view control messages, which can be generated by MAK applications such as MAK Data Logger, and by programs that use the VR-Vantage Control Toolkit. For details, please see “Controlling the Observer from Other Applications,” on page 49-34.
You can also send view control messages from plans. For details, please see “Sending View Control Messages,” on page 36-35.
The VR-Forces toolkit lets you develop CGF applications. You can enhance the capa- bilities of the VR-Forces simulation engine and GUI, or integrate the simulation engine into your own user interface. The toolkit has several APIs. The Simulation API gives you control over:
Behaviors
Components
Object types
Parameters
Messages
Resources
Tactical graphics
Plans
Tasks.
The Remote Control API allows you to control a VR-Forces simulation engine from a remote application, such as a graphical user interface (GUI). The Terrain API lets you manipulate terrain databases.
The VR-Forces front-end is built with the VR-Vantage Toolkit. The toolkit is included with VR-Forces, allowing you to modify or extend the front-end. For details about the VR-Forces Toolkit, please see VR-Forces Developers Guide.
You can modify the VR-Forces front-end and back-end by rebuilding the applications or by writing plug-ins. In fact, much of the basic functionality of the front-end is implemented using plug-ins rather than as part of the main executable. Plug-ins are dynamically linked libraries that VR-Forces can load at startup. The rationale for choosing which method to use is described in API documentation. You can manage the use of plug-ins in the front-end. For details, please see “Managing Plug-ins,” on
page 4-31.
Introduction to VR-Forces — Support for External Communications Servers
VR-Forces uses DI-Guy software and content for human character animation.
VR-Forces comes with DI-Guy functionality built-in and with a large set of DI-Guy characters, appearances, and animations. A VR-Forces customer does not need a DI- Guy license of any kind to use DI-Guy animated characters in a VR-Forces-based appli- cation (including custom applications built using the VR-Forces Toolkit).
However, you need a DI-Guy Developer’s license if you want to:
Develop new character types, or alter the geometry, appearances, textures, or motions of DI-Guy characters.
Directly access the DI-Guy API to modify or extend the way that VR-Forces uses the DI-Guy API or access DI-Guy functionality that MAK has not already inte- grated into VR-Forces.
DI-Guy libraries, models, textures, motion files, and other graphics resources are distributed in the VR-Forces package solely so that VR-Forces can use them. Use of DI- Guy software or content outside of VR-Forces-based applications is not permitted by the VR-Forces license.
For more information, please see “DI-Guy Animation,” on page 29-5 and “DI-Guy Characteristics (Appearance, Head, Body Weight),” on page 34-16, and “DI-Guy Configuration Files,” on page 68-3 and “Editing a Lifeform’s Visual Model and Anima- tion,” on page 65-16.
You can configure VR-Forces to use an external communications effects server to control the transmission of radio messages between VR-Forces simulation objects. The communications effects server determines which simulation objects are able to commu- nicate with each other, and how long it takes a message to be transmitted from the orig- inator of the message to the receiver of the message.
Any communications effects server that meets the defined interface can be used. For information about the interface, please contact support@mak.com. For more informa- tion, please see Chapter 13, Using a Communications Effects Server.
Introduction to VR-Forces — Helpful Utilities
VR-Forces includes the following utilities for configuring and troubleshooting VR- Forces:
The Simulation Object Editor is a graphical user interface that lets you add and remove component systems from simulation objects and specify common simula- tion object parameters. You can create new simulation objects in the editor. You can also create new simulation model sets. The Simulation Object Editor is also used to manage tactical graphics. For details, please see Chapter 64, The Simulation Object Editor and SMSs.
The Object Parameter Database (OPD) Editor is a graphical user interface for editing the object parameter database. Using the OPD Editor can speed up editing of the object parameter database and prevent syntactical errors that can occur when you use a text editor to edit parameters. For details, please see Chapter 70, Using the OPD Editor.
The vrfMsgDump utility displays the contents of VR-Forces messages discovered on the network.
The Boundary Generation Tool lets you calculate the boundaries of a high resolu- tion terrain inset for inclusion in an earth file. For details, please see“Using the Boundary Generation Tool,” on page 57-15.
The medfTool lets you encrypt 3D model files. For details, please see “Compressing Model Files,” on page 83-27.
The mftTool lets you process MetaFlight terrains so that they will work in VR- Forces. For details, please see “The mftTool,” on page 60-4.
osgearth_cache. This utility lets you cache terrain data from earth files offline. For details, please see “Caching earth File Terrain Data Offline,” on page 61-5.
The VR-Forces front-end includes software and content licensed from third parties, including:
SilverLining™: real-time sky and 3D cloud rendering from Sundog Software.
Triton Ocean SDK™: 3D ocean and ship wakes from Sundog Software.
GL Studio®: interactive cockpit instrumentation and HMI from DiSTI®.
SpeedTree®: animated, 3D foliage from Interactive Data Visualization (IDV).
3D models, terrain, and graphical content from Simthetiq, RealDB, TurboSquid, and TerraSim.
OpenSceneGraph: an open source 3D graphics toolkit hosted at http://www.open- scenegraph.org.
osgEarth: an open source streaming terrain plug-in by Pelican Mapping, at http://osgEarth.org.
!
!
The run-time and developers’ rights for VR-Forces customers vary from vendor to vendor. Please read this section carefully to understand which rights are included with VR-Forces licenses, and which rights require additional third-party licenses.
Most VR-Forces customers do not need to buy a SilverLining license of any kind. In general, a VR-Forces customer has the right to use the SilverLining technology that is built into VR-Forces in any VR-Forces-based application (including custom applica- tions built using the Toolkit). However, there are two exceptions:
If you want to extend or change the way that MAK has integrated SilverLining into VR-Forces by writing directly to the SilverLining API, then you need a SilverLining Developer’s License.
If you are building a commercial video game or other “mass-market” (consumer- level) commercial product on top of the VR-Forces Toolkit, and the resulting product includes the SilverLining functionality, then you need a SilverLining Developer’s License.
SilverLining libraries, textures and other graphics resources are distributed in the VR- Forces package solely so that VR-Forces can use them. Use of SilverLining software or content outside of VR-Forces-based applications is not permitted by the VR-Forces license.
Introduction to VR-Forces — Third-Party Software and Content
VR-Forces uses the Triton Ocean SDK to render 3D oceans and ship wakes. Triton Ocean is developed by Sundog Software (http://www.sundog-soft.com).
Most VR-Forces customers do not need to buy a Triton Ocean license of any kind. In general, a VR-Forces customer has the right to use the Triton Ocean technology that is built into VR-Forces in any VR-Forces-based application (including custom applica- tions built using the Toolkit). However, there are two exceptions:
If you want to extend or change the way that MAK has integrated Triton Ocean into VR-Forces by writing directly to the Triton Ocean API, then you need a SilverLining Developer’s License.
If you are building a commercial video game or other “mass-market” (consumer- level) commercial product on top of the VR-Forces Toolkit, and the resulting product includes the Triton Ocean functionality, then you need a Triton Ocean Developer’s License.
Triton Ocean libraries, textures and other graphics resources are distributed in the VR- Forces package solely so that VR-Forces can use them. Use of Triton Ocean software or content outside of VR-Forces-based applications is not permitted by the VR-Forces license.
VR-Forces is delivered with several generic cockpit displays. You can use the built-in cockpit displays in any VR-Forces-based application (including custom applications built using the Toolkit), without a GL Studio license of any kind.
If you want to build custom cockpits using the GL Studio editor or GL Studio API, you need a GL Studio Developer’s license. If you want to execute custom cockpits in VR- Forces-based applications (regardless of whether the custom cockpits are built by you or a third party), you need GL Studio Run-Time licenses.
GL Studio libraries and graphics resources are distributed in the VR-Forces package solely so that VR-Forces can use them. Use of GL Studio software or content outside of VR-Forces-based applications is not permitted by the VR-Forces license.
A VR-Forces customer does not need a SpeedTree license of any kind to use the SpeedTree functionality that is built into the VR-Forces applications that MAK delivers. You may build and run plug-ins to our out-of-the-box applications without a SpeedTree license, as long as your plug-ins do not need to directly access the SpeedTree API.
However, you need a SpeedTree Developer’s license if you want to:
Write a plug-in that uses the SpeedTree API directly to extend or modify the way that SpeedTree is integrated into VR-Forces.
Use the VR-Forces Toolkit to develop new applications, and you want your appli- cations to include SpeedTree functionality.
SpeedTree libraries, models, textures, and other graphics resources are distributed in the VR-Forces package solely so that VR-Forces can use them. Use of SpeedTree software or content outside of VR-Forces-based applications is not permitted by the VR-Forces license.
VR-Forces includes a rich set of 3D models for vehicles, weapons, cultural features and urban clutter (signs, barriers, lampposts, and so on). It also includes several sample terrain databases to help you get started with VR-Forces, and to help demonstrate VR- Forces. Much of this content is derived from 3D data that we have licensed from third parties:
Many of the high-quality vehicle models come from Simthetiq (http://www.simthetiq.com).
Some models come from Real DB (http://www.realdb.qc.ca/company).
Some of the middle-eastern building models and urban clutter objects that are used in our sample terrain databases were licensed from Turbosquid (http://www.turbos- quid.com).
All of this content is distributed in the VR-Forces package solely so that VR-Forces can use it. Use of any of the VR-Forces models, textures, terrains, or other content outside of VR-Forces-based applications is not permitted by the VR-Forces license.
Introduction to VR-Forces — Distributed Simulation Standards Supported
VR-Forces uses OpenSceneGraph for its underlying scene graph representation, rendering, file loading, and many other capabilities. OpenSceneGraph is an open source, cross-platform graphics toolkit for the development of high-performance graphics applications. The OpenSceneGraph source repository is maintained by Robert Osfield at http://www.openscenegraph.org/projects/osg. It is distributed under the OpenSceneGraph Public License (OSGPL), which is based on the GNU Lesser General Public License (LGPL).
MAK will provide modified source code for OSG upon request, as per the OSGPL license. Please contact support@mak.com to obtain the download links for our modi- fied source.
VR-Forces uses osgEarth to import streaming terrain elevation and imagery data. The data can be streamed from external servers and sources or from a directory on the computer running VR-Forces. osgEarth is an open source plug-in to OpenSceneGraph, maintained by Pelican Mapping at http://osgEarth.org. osgEarth is distributed under the GNU Lesser General Public License (LGPL).
MAK will provide modified source code for osgEarth upon request, as per the OSGPL license. Please contact support@mak.com to obtain the download links for our modi- fied source.
VR-Forces supports the HLA 1.3 specification, the current draft of the IEEE 1516 C++ API maintained by the SISO Dynamic Link Compatible RTI API Product Develop- ment Group, and HLA Evolved (IEEE 1516-2010). It also supports the Distributed Interactive Simulation (DIS) protocol, versions 4, 5, 6, and 7.
VR-Forces has built-in support for the HLA RPR-FOM and can support other FOMs through the FOM Mapping feature. For information about FOM mapping, please see “Specifying a FOM Mapper,” on page 5-18. Please see VR-Forces Release Notes for a list of the versions of DIS supported.
VR-Forces supports time management for HLA exercises.
This chapter explains how to install VR-Forces on your computer. It also explains how to install other software required for use with VR-Forces.
Installing VR-Forces on Windows 2-2
Installing VR-Forces on a Linux System 2-3
The VR-Forces Directory Structure 2-4
Installing and Setting Up the MAK License Manager 2-5
Specifying the License Server 2-6
Localizing the Graphical User Interface 2-10
Translating Other Interface Files 2-13
Translating VR-Forces Scripts and Console Messages 2-14
Applying the Language Files 2-15
Merging Translation Files 2-15
Installing VR-Forces
Before you install VR-Forces, please read the Release Notes to see if there are any special instructions for installation.
VR-Forces has two installation files, an application installer and a data package (.MAK- targz). You must run the application installer and then install the data package. The application installer can automatically install the data package if you configure it to do so.
To install the VR-Forces toolkit, you must enter an installation code. Be sure you have received your code from your MAK salesperson before you start the installation process. If you do not have an installation code, you can install the runtime files. When you receive your installation code you can install the toolkit.
Note the following:
You must have administrator privileges to install MAK products on Windows Vista.
When you install large applications on Windows Vista or later, there may be a delay of up to several minutes from the time you try to run the setup program to the time that an installation dialog box is displayed. This is due to how Windows scans setup programs before it executes them. If you experience this problem, turning off User Access Control can reduce or eliminate this delay.
Windows versions of VR-Forces are provided as executable installer files on DVD, or as downloaded files. The installers are named to indicate the compiler used to build that version of VR-Forces.
To install VR-Forces, run the application installer. Follow the instructions in the installation wizard. You can specify that the application installer automatically find and install the data package (it must be in the same directory as the application installer), or you can specify that the MAK Data Installer open and let you select the data package to install.
Installing VR-Forces — Installing VR-Forces
Linux versions of VR-Forces are provided as compressed tar files on DVD, or as down- loaded files.
If you install VR-Forces in one directory and user data in another directory, VR-Forces will not start.
To install VR-Forces on Linux:
Create the directory in which you want to install VR-Forces.
Copy the tar file to the install directory.
Uncompress and untar the application file:
tar -vxzf application.tar.gz
where application is the product release identification.
The data package has the extension MAK-targz. Uncompress and untar the data package and copy it into the installation directory, or uncompress it and redirect the output, as follows:
tar -xzf makData<version>.MAK-targz -C /path-to-vrforc- es4.5
If you are installing from a DVD, the data package is too large to fit on a single DVD and has been broken up into smaller files. You must put these files back together before you can install the data. Follow the instructions in VR-Forces Data Package Installer Readme.txt, which is included on the DVD.
When you uninstall VR-Forces, the uninstaller does not uninstall the data package. You must delete the files manually.
Installing VR-Forces — The VR-Forces Directory Structure
The VR-Forces installation process creates a directory structure like the one shown in Figure 2-1. On PCs, the default installation directory is C:\MAK\vrforces4.5.)
vrforces4.5
appData appsrc backup
bin64 compatibility data
doc examples factory include lib64 plugins64 translations userData
Figure 2-1. VR-Forces directory structure
Table 2-1 describes the contents of the directories installed by VR-Forces.
Table 2-1: Contents of VR-Forces directories (Sheet 1 of 2)
Directory Directory contents
Directory Directory contents
./appData Schema, model definitions, settings, configuration files, and other data.
./appsrc Source files and project files for API developers.
./backup Backup configuration files.
./bin64 or ./bin Product executables and DLLs.
./compatibility Header files for compatibility with releases before VR-Forces 4.3.
./data The ./data directory has several subdirectories that contain:
Bitmaps and icons.
Simulation model sets.
Terrain database source files.
Visual model data.
./doc VR-Forces documentation.
./examples Sample code for toolkit users.
./factory Backups of the application data and settings provided by MAK.
./include Header files for use by API developers.
./lib64 or /lib Library files.
Table 2-1: Contents of VR-Forces directories (Sheet 2 of 2)
Directory Directory contents
Directory Directory contents
./plugins64 or
./plugins
Plug-in DLLs.
./translations Files and an executable for localizing the GUI.
./userData Scenarios, terrain files, and other files that get created by users as they use VR-Forces.
If you have already installed the License Manager for another MAK product, you do not have to install it again. You just need to make sure you have licenses for your newly installed products.
The License Manager installer is included on MAK installation media. It is separate from the product installers. You can download the installers from our web site at http://www.mak.com/license-support.html or you can download directly from:
Windows:
ftp://ftp.mak.com/out/MAKLicenseManager-win64-setup.exe
Linux:
ftp://ftp.mak.com/out/MAKLicenseManager-linux64-setup.tar.gz
Complete installation and configuration instructions are included with the License Manager installer. Instructions are also available at the license support page.
Some customers use dongle licenses instead of running a license server. Instructions for using dongles are in the License Manager documentation.
Installing VR-Forces — Installing and Setting Up the MAK License Manager
The first time you run a MAK application on a particular computer, the License Setup dialog box opens (Figure 2-2). It prompts you to enter the hostname of the license server and optionally, a port number.
Figure 2-2. License Setup dialog box
If you do not know the hostname of the license server, click Configure Later. When you have the hostname, you can start the application again and complete the dialog box.
You will not be able to run any MAK applications until you set up license management.
If you know the hostname, type it in the Hostname box. Then click OK. The applica- tion will start.
Under limited circumstances, MAK issues node-locked licenses. If you have a node locked license, select the Use Node Locked License option and enter the path to the license file.
If you are running MAK products on the license server machine, it is also a client, so you must specify the license server on that machine too.
If you change the license server, the saved configuration will no longer be valid and the License Setup dialog box will open the next time you start a MAK application.
You can clear the saved license configuration by deleting the cache file. On Windows, it is C:\Users\user_name\AppData\Roaming\MAK\licenses<n>.txt. (The AppData directory is hidden by default.) On Linux, it is
.mak/license<n>.txt. (There may be more than one cache file, for example, licenses1.txt and licenses2.txt.)
The syntax for the environment variable is: @Server_name. For example, if the server machine is oak, set the environment variable to @oak.
The following sections explain how to set environment variables on the different plat- forms that MAK products run on.
To add the MAKLMGRD_LICENSE_FILE in Windows:
Open the Control Panel.
Click System and Security.
Click System.
In the sidebar menu, click the Advanced System Settings. The System Properties dialog box opens.
Click Environment Variables. The Environment Variables dialog box opens.
Click New. The New System Variable dialog box opens.
In the Variable Name field, enter MAKLMGRD_LICENSE_FILE.
In the Variable Value field, enter @server_name, where server_name is the name of the license server.
Click OK to back out of each dialog box and set the variable.
Installing VR-Forces — Installing an RTI
Different versions of Windows have slightly different wording of the various Control Panel options.
On Linux, you set environment variables in your .cshrc (or equivalent startup file). Set the variable similarly to the following example:
setenv MAKLMGRD_LICENSE_FILE @oak
If you are using the sh or bash shells, you set environment variables in your .profile file (or .bashrc). Set the variable similarly to the following example:
MAKLMGRD_LICENSE_FILE=@oak export MAKLMGRD_LICENSE_FILE
Do not put spaces around the equal (=) sign.
You are ready to run the license server and use your new licenses or MAK products.
An RTI is a software library (and perhaps supporting executables) that implements an HLA Interface Specification. In HLA, applications exchange FOM data through RTI calls, which means that all HLA applications need to use an RTI.
Because of differences in the low-level network mechanisms used by different RTI implementations (which include, but are not limited to packet layout), applications that want to interoperate in the same federation execution must use the same RTI implementation.
Because RTIs are usually provided as dynamic libraries that implement a fixed API, a federation can often switch from one RTI implementation to another between runs (without even recompiling the applications), but during each run, all participants must agree on which RTI to use, much as they must also agree on which FOM to use.
For the most recent information about the RTI versions supported by MAK products, please see the release notes for your MAK application.
Installing VR-Forces — Installing an RTI
To install the MAK RTI, follow the instructions in Chapter 2 of MÄK RTI Users Guide.
Linux — LD_LIBRARY_PATH.
Windows — PATH.
The MAK RTI needs to know where to find the following configuration files:
The federation configuration file (.fed, .fdd, or .xml) for your federation execution (required).
The RID file (rid.mtl) (optional).
To run a MAK application with the MAK RTI:
Be sure the license server is running.
Start the application. The RTI Assistant will prompt you to choose an RTI config- uration.
Choose a configuration. If necessary start the rtiexec.
Click Connect. The application should run.
In many cases, you do not need to run the rtiexec to use the MAK RTI, however you can run the rtiexec if you want to. (It is required to use certain features of the MAK RTI.) For more information, please see your RTI documentation.
i If you are running VR-Forces, it is recommended that you run the rtiexec.
You can localize your MAK product’s graphical user interface so that it uses languages other than English. Your product includes a file called ./translations/product_untrans- lated.ts, for example logger_untranslated.ts or vrforces_untranslated.ts. The file contains entries for all of the application-specific menu and dialog box text. The Qt Linguist tool, which is included with VR-Forces, lets you map the English text provided by MAK to your chosen language.
The untranslated.ts file does not include all of the text that may be displayed in the GUI or in console and error messages.
Some strings, such as those on the Create menu, are in configuration files. Others are in settings files. You can translate these strings by identifying the appropriate configuration file and translating the strings.
VR-Forces has a utility that can scan system scripts and SMS files and create translation files for user-visible text. For details, please see “Translating VR- Forces Scripts and Console Messages,” on page 2-14.
Start the Qt Linguist utility. It is ./translations/linguist.exe
In the Qt Linguist window, choose File Open. Select the file ./transla- tions/product_untranslated.ts. The Settings for filename dialog box opens (Figure 2-3).
Select values for the source language, target language, and target region or country.
Click OK. The translation file is opened and a list of classes is displayed on the left side of the window (Figure 2-4).
Source text
Class
list
Translation area
To translate text, you select each class in turn and translate the text associated with that class. You do not have to understand anything about what the classes mean, you just have to translate the text. In Figure 2-4, QMenu is selected. The Strings window lists text that can be translated. Text that has not been translated has a question mark in the checkmark column.
In the Source Text list, select the word you want to translate. The text is displayed under Source Text in the translation area (the window below the source text list.) Figure 2-5 shows the text Open selected.
Place the cursor in the text box below Language Translation, where Language is the target language that you selected when you opened the translation file.
Type the translation text.
When you are done and you are certain of the translation, select the Done and 
Next button on the toolbar. A green check mark replaces the question mark
(Figure 2-6). If you move to a different text string without clicking Done and Next, a yellow question mark is displayed for the string you translated. When you trans- late all elements for a class, a green check mark replaces the question mark next to the class name.
Repeat this process for each element of source text for each class.
Choose File Release. The file is saved in the format filename.qm.
Rename the file to a name that indicates the language to which you have translated the file, using the two-character abbreviation typically used with your language. For example, a Spanish translation would be renamed product_es.qm.
Save your translated .ts file.
The vrforces_untranslated.ts file contains all the text used in the VR-Forces interface. However, there may be other text and messages that are not specific to VR-Forces that are generated by the software that implements the VR-Forces GUI. To translate this text, you need to translate the file qt_untranslated.ts. Follow the same procedure as you did for vrforces_untranslated.ts.
The vrforces_untranslated.ts file includes text for dialog boxes and interface elements created using the Qt Toolkit. However, there are many messages generated by code and the dialog boxes for scripts are generated programmatically, rather than through Qt ui files. Therefore they are not included in vrforces_untranslated.ts. VR-Forces has a utility that can scan all system scripts (those in a simulation model set) as well as some of the common SMS files, and create a TS file for each script and SMS. You can then translate the text in the individual TS files. This script also creates a TS file for DI-Guy files.
For this process to work, you must code messages in your scripts in a certain way. For details, please see “Coding Messages for Translation,” on page 33-21. VR-Forces also has a way to code console messages so that they can be extracted and translated. For details, please see 17.8.1, Coding Object Console Messages for Translation, in VR- Forces Developers Guide.
If you code your scripts to support translation, you create TS files by running the trans- lationFileCreate utility. By default this application scans ./data/simulationModelSets and its subdirectories for all system scripts and some generic files, and ./appData/settings for DI-Guy files.
The utility creates an untranslated.ts file for each lua script. This file is saved in the directory that contains the script. It also creates a TS file for each simulation model set, which is saved in the SMS directory, and a diguy_untranslated.ts file, which is saved in
./translations.
When you translate a script file, the translated file must remain with the back-end(s) that are hosting the scripts. The rest of the translated files must exist on the user machine. The .qm file for DI-Guy and VR-Forces must live in the translations directory and the .qm file for the simulation model sets with the .sms files.
The syntax for translationFileCreate is as follows:
translationFileCreate.exe [--directory filename] ... [--smsfile string] ... [--nodiguy] [--nosms]
[--noscripts] [--] [-v] [-h]
Table 2-2: translationFileCreate arguments
Argument Description
Argument Description
--directory
directory_name
Directory to scan for files of any of the supported types (lua, sysdef, xml, mtl) as per creation rules (scripts, systems, supporting). Accepted multiple times.
(-h | --help) Displays usage information and exits.
--nodiguy Do not parse the DI-Guy configuration files.
--noscripts Do not parse Lua files for translation.
Table 2-2: translationFileCreate arguments
Argument Description
Argument Description
--nosms Do not parse the simulation model set directories for their supporting translatable items.
--smsfile
SMS_filename
Specific SMS file to use when translating simulation model set directories. Accepted multiple times. If not specified, processes all SMS files.
(-v | --version) Displays version information and exits.
(-- | --ignore_rest) Ignores the rest of the labeled arguments following this
flag.
If the messages in your source code are coded for extraction to TS files, you can generate an untranslated.ts file for them. To generate TS files, run:
lupdate source_directory -ts my_new_translations.ts
The resulting TS file is saved to the location pointed to by the path given to -ts.
To put the language file into effect, use one of the following methods:
Set your computer’s environment to the proper language (LANG environment variable).
Set the locale to the proper language.
Start VR-Forces with the -G locale command line option, where locale is the two-letter country code for the local language.
If you localize a version of VR-Forces and upgrade to a newer version, you can merge your localized .ts file with the .ts file from the new version. Then you only have to trans- late new or changed text in the new version. You merge translation files with the trans- lationMerge utility, which is in the ./bin64 directory. The syntax is as follows:
translationMerge [-o] [-m] previous.ts current.ts new.ts
where:
previous.ts is the name of the previously localized translation file.
current.ts is the name of the translation file provided with the current release of VR-Forces.
new.ts is the name to give to the merged file.
-o specifies that the merged file removes obsolete messages.
-m merges modules that have equal text strings.
3. VR-Forces Application Concepts
This chapter describes at a conceptual level the components of a VR-Forces simulation and how they work together.
Front-end and Back-end Concepts 3-2
How Front-ends and Back-ends Work Together 3-3
How VR-Forces Back-ends are Identified 3-4
Coordinating Multiple Front-ends 3-6
Working with Multiple Back-ends 3-7
The Object Parameter Database 3-8
Local Objects and Remote Objects 3-9
Representing and Managing Time in VR-Forces 3-10
Advanced Terrain Navigation 3-12
How Navigation Data is Generated 3-12
VR-Forces Application Concepts — The VR-Forces Program
Unlike most computer applications, which have one executable file, VR-Forces has two executable files: a front-end, or graphical user interface (GUI) and a back-end, or simu- lation engine. The front-end executable is vrfGui. The back-end executable is vrfSim- protocol, where protocol is DIS, HLA13, HLA1516, or HLA1516e.
By separating the simulation engine from the visualization program, VR-Forces allows you to run multiple front-ends, back-ends, or both. If you run multiple front-ends, several VR-Forces users can work together to create and manage scenarios. Using session IDs, you can specify which front-ends control which back-ends. The front-ends also display simulation objects received over the network from other simulations partic- ipating in an exercise. (You have a limited ability to interact with these remote objects. For more information, please see “Local Objects and Remote Objects,” on page 3-9, “Writing Plans for Remote Entities,” on page 36-39 and “Attaching VR-Forces Components to Remote Entities,” on page 76-2.)
If you run multiple simulation engines, the work of simulating simulation objects and tactical graphics can be shared by multiple computers, which should improve perfor- mance. If you save a scenario, VR-Forces records which objects are simulated by each back-end, so that the configuration can be reproduced the next time you run the scenario.
In this manual, most procedures apply to interaction with the front-end. For the sake of simplicity, unless we are discussing a subject that applies specifically to either the front-end or back-end, we refer to VR-Forces in the sense of the combined interactions of both executables.
How front-ends and back-ends work together.
How back-ends are uniquely identified.
Use of sessions.
How to coordinate multiple front-ends.
How scenarios are loaded and saved when you run multiple back-ends.
The VR-Forces front-end is an interface to the simulation engine. It communicates with the back-end by sending messages over the network. (This relationship exists even if you are not connected to a network.) It displays the state updates and interactions that the back-end generates and sends over the network. Figure 3-1 illustrates loading a scenario and running a simulation.
Front-end (GUI)
Load scenario
network
Back-end
Load terrain
Send load scenario message to back-end.
Scenario loaded message.
Update GUI
Load scenario message.
Scenario loaded message.
Load scenario Load terrain Create objects
Run simulation
Update GUI
Run simulation message.
State updates
Run simulation message.
State updates
Execute plans Simulate objects
= User action 
= VR-Forces action
Figure 3-1. Front-end and back-end interaction
If you run multiple back-ends, you can specify which back-end you want to use when you create simulation objects and tactical graphics. This feature allows you to spread the simulation load across multiple PCs. However, to do this, each back-end must have a unique ID. VR-Forces back-ends are identified by their site ID and application number. Each back-end must have a unique site:application identifier. You assign the site:application identifier when you start an application. It is up to you to make sure that there are no duplicate identifiers. (For details, please see “Starting VR-Forces,” on page 4-3.)
The site ID and application number concepts are borrowed from DIS. They apply to VR-Forces when it is running in HLA as well.
VR-Forces uses sessions to help manage the relationships between front-ends and back- ends. Back-ends are always part of a session. Front-ends can join a session or operate independently of one. When a front-end is joined to a session, it can control the back- ends in that session. When a front-end is not joined to a session, it cannot control back- ends. However, it can open a terrain and view exercises running on its port. In this case it is just a viewer.
Use of sessions helps ensure consistency among front-ends that are controlling a common set of back-ends. The session mechanism ensures that:
All front-ends and back-ends in a session run the same scenario and use the same terrain.
When a front-end joins a session that is running a scenario, it automatically loads the correct terrain for the scenario.
If any front-end in a session tries to create a scenario or load a scenario, and a scenario is already running, the user is warned that this action will destroy the currently running scenario.
If any front-end in a session loads a scenario or creates a new scenario, all of the back-ends and other front-ends in that session take the same action.
Sessions provide the following additional benefits:
They allow you to specify which front-ends control which back-ends. This feature could be useful, for example, if you want one set of VR-Forces applications to simulate friendly forces and another set to simulate opposing forces. If all applica- tions were in the same session, participants could send orders to the simulation objects in the opposing force. By using separate sessions, this is not possible.
In Figure 3-2, the front-end with session ID 1 can control the back-ends with that same session ID. The front-end with session ID 2, controls the back-end with session ID 2.
front-end
front-end
session ID 1
session ID 2 front-end
session ID 1 session ID 1 session ID 2
Figure 3-2. Using session ID to control back-ends
Sessions allow you to load different terrain databases in different VR-Forces execut- ables that are part of the same exercise. This feature may be helpful if you are participating in an exercise that covers a large geographical area, but only need to observe portions of that total terrain. Loading databases that cover a subset of the total exercise zone could improve the performance of your computer or the resolu- tion of the terrain database.
In Figure 3-3, the two sessions have loaded databases that cover different (but over- lapping) portions of California, USA. The entire exercise would cover the terrain covered by two databases.
session ID 1 session ID 2
Figure 3-3. Using session IDs to load different terrain databases
If two different sessions use terrain databases that overlap, note the following possible sources of confusion:
If you save the scenario in one of these sessions, it only saves the simulation objects simulated in the session. It does not save the simulation objects from the other session, even though they may be visible in a front-end.
If one of the sessions pauses or rewinds, the front-end in the other session will see the simulation objects in the overlapping region pause or return to their origin.
For more information, please see “Specifying a Session ID,” on page 4-8 and “Managing a Front-end’s Session Connection,” on page 4-14.
Figure 3-1 shows how a VR-Forces front-end sends messages to a back-end and displays the simulation messages sent out by the back-end. When you run VR-Forces with multiple front-ends, any of them can send control messages to the back-ends and all of them display the state updates. However, you would not want users at different front- ends to send conflicting or overlapping messages. For example, you would not want two different users to try to load the same scenario. Therefore, when you run multiple front-ends, bear the following points in mind:
Only one front-end in each session can load a scenario or create a new one (they can all create the objects in the scenario).
Any front-end can save a scenario. However, this could lead to multiple, unsyn- chronized versions of a scenario. It is probably best to reserve saving of scenarios to a specific front-end.
Any object that you create in any of the front-ends is visible in the others and can be managed from them.
You can close the scenario from any front-end.
VR-Forces provides some help managing multiple front-ends. For example, if one front-end loads a scenario, VR-Forces automatically asks the other front-ends to load the appropriate terrain. And if you close a scenario in one front-end, VR-Forces auto- matically prompts the other front-ends to close their terrains.
As noted previously, you can distribute simulation of simulation objects among multiple back-ends. The available back-ends are listed in the Selected Simulation Engine Toolbar (Figure 3-4). If you are running multiple back-ends, when you create simulation objects, you specify which back-end you want to create them on by selecting a back-end in the toolbar. (For more information, please see “Selecting the Object to Create,” on page 16-4.)
Figure 3-4. Selected Simulation Engine toolbar
When you run multiple back-ends, bear the following points in mind:
When you save a scenario created using multiple back-ends, the object map file (“The Object Map File,” on page 12-9) records each object and the site and appli- cation ID of the back-end on which it was simulated. When you want to replay that scenario, you should run a set of back-ends with the same site and application IDs. (If you do not, you can remap objects to the back-ends that you are running.)
If you want a back-end to join an exercise after it has started, you must explicitly load the terrain database using -T command-line option. The back-end will not receive any order of battle data, but it can be used to create new simulation objects and tactical graphics going forward in the simulation.
VR-Forces Application Concepts — Objects
If a scenario is missing its object map (.omp) file, you can remap the objects and create a new object map file. By default, in combined mode all the simulation objects are remapped to the combined mode back-end. By default, in separate mode the remap- ping dialog box lists the missing back-end as “UNKNOWN”.
You might also want to manually remap back-ends to load balance a scenario. For more information, please see “Load Balancing a Scenario,” on page 7-19.
VR-Forces creates objects based on parameter specifications in the object parameter database (OPD). In the OPD, object types are identified by an 8-field enumeration based on the SISO Enumeration Document (Reference for Enumeration for Simulation Interoperability). (The DIS enumerations have also been incorporated into the HLA RPR FOM.) In this manual, when we refer to entity or force type enumerations, we are referring to this set of enumerations. For information about the object parameter data- base and how to edit it, please see the chapters in Section XI, Creating and Editing Simulation Models.
The objects in the OPD are organized into simulation model sets (SMS). An SMS contains all of the objects and supporting configuration files needed to populate a scenario. VR-Forces provides an SMS for entity-level scenarios (EntityLevel.sms), one for aggregate-level scenarios (AggregateLevel.sms), and one used by both types of scenarios (base.sms).
VR-Forces Application Concepts — Objects
From the point of view of a particular VR-Forces back-end, a local object is any object that is simulated in that back-end. In that same back-end, a remote object is an object that is received over the network from an external application, such as another VR- Forces simulation engine, or a non-VR-Forces simulation. A given VR-Forces applica- tion participating in a networked exercise may know about a mixture of local and remote objects.
There are two categories of remote objects: objects simulated by VR-Forces applica- tions, and objects simulated by applications other than VR-Forces. When VR-Forces learns about a non-VR-Forces remote object, it knows only what is transmitted in the standard DIS or HLA message. By contrast, VR-Forces remote objects share additional state information over the network, including a unique identifier (UUID), a string name, an echelon ID (if the simulation object is organized), and a string label.
You cannot control remote simulation objects from VR-Forces. However, you can attach VR-Forces components such as sensors and radios to remote simulation objects and you can write plans that use these components. For more information, please see “Writing Plans for Remote Entities,” on page 36-39 and “Attaching VR-Forces Components to Remote Entities,” on page 76-2.
VR-Forces Application Concepts — Representing and Managing Time in VR-Forces
VR-Forces maintains an exercise clock. The clock keeps track of elapsed simulation time, date, and time of day. In HLA federations, it may be affected by federation time. These concepts also have a relationship to wall-clock, or real time.
Elapsed simulation time is the amount of time that has passed since the simulation started, and is expressed in days, hours, minutes, and seconds in the format 00:00:00:00.
Application developers can manipulate simulation time. Unless a local developer tells you otherwise, simulation time starts at 00:00:00:00.
Simulation starts
End of 24 hrs.
End of 36 hrs.
End of 48 hrs.
00:00:00:00 01:00:00:00 01:12:00:00 02:00:00:00
Elapsed simulation time
Figure 3-5. Simulation time
VR-Forces represents the day/night cycle with the Time of Day value. By default, it starts at 10:00 A.M in the time zone of the first simulation object created in a scenario, but can be set when you create a scenario. Time of day affects the simulation. For example, visual sensors are less able to detect objects at night than they are in the day.
Normally, time of day advances with simulation time, however you can change the time of day after the scenario is created, and even while the scenario is running. You can reset the time of day at any time through the environment settings, or through a plan with the Set Time of Day command. For details, please see “Introduction to Environment Conditions,” on page 11-2.
The display of time of day in the interface is 00:00 in hours and minutes. Time of day does not track number of days; when the time of day reaches midnight, is starts over at 00:00.
VR-Forces Application Concepts — Representing and Managing Time in VR-Forces
The exercise clock supports the following modes:
Fixed-Frame Best-Effort mode advances simulation time by a fixed amount each frame, even if a frame takes longer than the fixed amount to compute. If the simu- lation takes less than the fixed frame time to compute, it waits until the frame time has elapsed before starting another.
Fixed-Frame Run-To-Complete mode advances simulation time by a fixed amount each frame, even if a frame takes longer than the fixed amount to compute, just as in Fixed-Frame Best-Effort mode. However, if the simulation takes less then the fixed frame time to compute, it does not wait for the remainder of the frame time to elapse before starting the next frame.
This mode is most useful for situations where you want a simulation to run with internal consistency and high fidelity, and want it to run to completion, but do not need to observe the simulation. So, for example, you might run a simulation over- night and view the results the following day. Fixed-Frame Run-To-Complete mode is not suited for interactive use. It is suitable for distributed use only in time- managed HLA federations.
VR-Forces supports simulation at rates faster than real-time by applying a multiplier to the tick time.
Do not run your simulation at faster than real-time if you are interacting with other real-time simulations.
Running a simulation faster than real-time can cause performance of simulation object models to degrade.
VR-Forces Application Concepts — Interactions
VR-Forces displays interactions, such as detonations, that it receives in interaction messages or PDUs. You cannot select or otherwise manipulate them. You can only view them.
Gameware Navigation Lab is included with VR-Forces. You can use it to view the navigation data included with VR-Forces terrain databases. If you want to generate navigation data, you must purchase an additional license.
Navigation data is generated from the front-end. Before you can use newly generated navigation data, you must close your scenario and reopen it. (This is so it can be loaded by the back-end.) If the terrain is modified, the navigation data must be generated again.
VR-Forces analyzes the terrain and creates a navigation mesh (NavMesh) of the terrain. The NavMesh defines areas in which an entity can move, given its dimensions. A life- form can move in spaces that a ground vehicle cannot move in. Figure 3-6 shows a NavMesh for a terrain that has several areas in which entities cannot move.
Obstacle
Obstacle Obstacle
Based on the NavMesh, VR-Forces generates a graph of locations in the terrain that the entity type can move to. Each location can be accessed from at least one other location. Figure 3-7 shows a hypothetical graph of the paths that an entity can follow in the NavMesh shown in Figure 3-6.
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
For details about generating navigation data, please see Chapter 58, Generating Naviga- tion Data.
Path finding is the process by which an entity plans a path, follows the path, and avoids obstacles along the path.
Every time an entity decides to move (either through an autonomous decision or a task assignment), it computes its path. Path computation, or path planning consists of running an A* algorithm, with a given heuristic, on the navigation data.
Start
Start
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
A path finding heuristic is a cost estimate for the shortest path to reach a target. This cost can be measured according to various criteria, such as distance, time, and danger. The path finding heuristic is critical for the performance of the A* algorithm used by VR-Forces.
The standard path finding heuristic is the Euclidian Heuristic. In this heuristic, the cost of moving from one vertex to another vertex is the Euclidian length of the connecting edge. VR-Forces also uses a Road Constrained Heuristic, in which a ground vehicle computing its path is forced to move only on roads.
Once a path is determined for an entity, it can start moving to its final goal. As illus- trated in Figure 3-8, a path is a set of vertices and edges. However, entities do not neces- sarily follow the exact path. VR-Forces smooths the entity’s movement.
Figures 3-9 and 3-10 illustrate this process. Using the prospective path defined in Figure 3-8, the entity computes its actual path. In Figure 3-9, view 1, it tests the first three vertices (dashed lines) and finds that it can reach all of them directly. In Figure
3-9, view 2, it tests the fourth vertex and finds that it can reach it. It then tests the fifth vertex and finds it cannot reach it directly. Therefore, the fourth vertex becomes the subgoal for this portion of the path. Figure 3-10 shows the final calculated path (dashed line). Notice how the path to the fourth vertex is much smoother than a path that strictly follows the vertices and edges would be, because the entity determined that it could move directly to that vertex.
Start
Start
Start
Start
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
1 2
Figure 3-9. Checking next vertex
Start
Start
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
Figure 3-10. Final calculated path
While following its path, an entity may encounter other entities. VR-Forces models include collision avoidance. However in complex scenarios, the scenario developer may have to spend a considerable amount of time creating routes and coordinating entities to minimize collisions among entities and obstacles.
Advanced navigation uses a dynamic avoidance algorithm to make entities behave real- istically when they are about to collide. Entities detect potential collisions in advance and adjust their trajectories smoothly using the navigation data.
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
Figure 3-11. Collision avoidance
In Figure 3-11, two entities traveling in opposite directions avoid each other, then resume their routes. Compare the track of the dashed line to that in Figure 3-10.
This chapter explains how to start and stop VR-Forces and load terrain databases.
Starting VR-Forces from the VR-Forces Launcher 4-3
Starting Independent VR-Forces Executables 4-8
VR-Forces Startup Tutorial 4-9
Printing the VR-Forces Display 4-13
Managing a Front-end’s Session Connection 4-14
Configuring Session Messages and Join at Startup 4-16
Using HLA Time Management 4-17
VR-Forces Simulation Time Versus Federation Time 4-18
Configuring Time Management for HLA Exercises 4-18
Opening a Terrain Database 4-19
Loading a Terrain Database at Startup 4-21
Managing VR-Forces Settings 4-21
Synchronizing Settings Among VR-Forces Installations 4-23
Global Settings and Observer-Specific Settings 4-24
Configuring Simulation Connections 4-24
Opening the Simulation Connections Configuration Dialog Box 4-25
Starting VR-Forces
Adding a Simulation Connection 4-26
Editing a Simulation Connection 4-27
Simulation Connection Parameters 4-28
Deleting a Simulation Connection 4-30
Displaying Connection Information 4-31
Specifying the DLLs for a Plug-in 4-35
Adding a Plug-in Configuration 4-36
Deleting a Plug-in Configuration 4-36
Viewing a List of Loaded Plug-ins 4-37
In “The VR-Forces Program,” on page 3-2, we describe the VR-Forces front-end and back-end applications. You can start front-ends and back-ends separately, which is called separate mode, or you can use the VR-Forces Launcher to start them together, which is called combined mode. The only real difference between the two startup modes is that in combined mode, when you shut down the front-end, the back-end automatically shuts down also.
If you run VR-Forces for HLA, be sure that you have installed an RTI and configured your system to use it. For details, please see “Installing an RTI,” on page 2-8.
For convenience you can create batch files or scripts to start VR-Forces. Please see Chapter 5, Command-line Options for a list of command-line options.
The VR-Forces Launcher lets you start in combined mode or separate mode.
To start VR-Forces using the VR-Forces Launcher:
On the Start menu, choose Programs MAK Technologies VR-Forces 4.5 VR- Forces configuration.
Where configuration is:
VR-Forces GUI
VR-Forces Simulation Engine
VR-Forces GUI + Simulation Engine.
1.
Windows 10 has a flatter Start menu structure than previous versions of Windows. It does not support nested folders. In the interest of simplicity, for the rest of this manual, instructions for starting applications will use the full folder path of Windows 8 and earlier. Windows 10 users should assume that all applications, tools, and documents are under All apps MAK Technologies. If you are interested in using a nested menu for starting application on Windows 10, please read this blog: http://www.mak.com/connect/blog/entry/tech-tip-from-fred-starting-mak- applications-on-windows-10
To start the Launcher on Linux (or from the Windows command line), in a console window, enter the following command:
vrfLauncher options
For descriptions of the vrfLauncher command-line options, please see “Command- line Options for vrfLauncher,” on page 5-14. The basic startup configurations for vrfLauncher are:
Start vrfGui and vrfSim (combined mode):
vrfLauncher
Start vrfGui only:
vrfLauncher -F
Start vrfSim only:
vrfLauncher -B
Start in combined mode and do not display the Simulation Connections Configuration dialog box:
vrfLauncher --usePredefinedConnection DIS
Figure 4-1. Simulation Connections Configuration dialog box (DIS)
In the Simulation Connections Configuration dialog box, select a connection configuration. (Optionally, create a new configuration. For details about creating and editing simulation connections, please see “Configuring Simulation Connec- tions,” on page 4-24.)
Optionally, edit the connection’s parameters. If you change a parameter, it is saved automatically.
Optionally, specify additional command line arguments for the front-end, back- end, or both. For a list of command line arguments, please see Chapter 5, Command-line Options.
If you click the Browse button at the end of the Additional Command Line Arguments entry for the front-end or back-end, VR-Forces displays the command that will be executed when you click Launch. You can copy the command and use it in a batch file, script, or for debugging.
If you start the Launcher from the command line and use the F-- or B-- syntax, those commands are not shown as additional command line arguments. However, they will be executed when you click Launch.
Click Launch. The VR-Forces executables start. When the VR-Forces applications finish their startup process, the Scenario Startup dialog box opens (Figure 4-2). It lets you quickly create or load a scenario using common options.
Figure 4-2. Scenario Startup dialog box
To create a scenario or load a scenario, select one of the options and click OK. The options are as follows:
New scenario. Select a terrain and simulation model set. VR-Forces creates a scenario using default scenario parameters. To specify scenario parameters when you create a new scenario, please follow the procedure in “Creating a Scenario,” on page 7-3.
Load a scenario. Choose a scenario from the recently used list or select Load Scenario From Disk. If you choose the latter, when you click OK, a file chooser dialog box opens. This option is the same as choosing File Load Scenario in the front-end.
If you do not want any of the options, click Close. (This closes the Scenario Setup dialog box; it does not close VR-Forces.)
To enable or disable the Scenario Startup dialog box:
Choose Settings Application. The Application Settings dialog box opens.
Select the Session Options page (Figure 4-3).
Select or clear the Show Scenario Startup Dialog check box.
You can also disable display of the Scenario Startup dialog box by selecting Do Not Show This Dialog At Startup on the dialog box itself.
To start independent VR-Forces executables:
Open a console window.
Change to the ./bin64 directory.
Enter a command for each VR-Forces executable you want to run. You must specify the protocol to use. For vrfSim, the protocol is part of the executable name. For vrfGui, it is a command-line argument. Specify a unique site:application iden- tifier for each executable, for example:
vrfGui -s 1 -a 3000 {--dis | --hla13 | --hla1516 |
--hla1516e} options
vrfSimprotocol -s 1 -a 3001 options
vrfSimprotocol -s 2 -a 3001 options
where protocol is DIS, HLA13, HLA1516, or HLA1516e.
A VR-Forces window opens for each front-end you start and a console window opens for each back-end. For an example of running multiple front and back-ends, please see “VR-Forces Startup Tutorial,” on page 4-9.
To assign a session ID, use the -i command line option.
vrfGui -s 1 -a 3000 -i 25 {--dis | --hla13 | --hla1516 |
--hla1516e} options] vrfSimprotocol -s 2 -a 3002 -i 25
where protocol is DIS, HLA13, HLA1516, or HLA1516e.
The default session ID is 1. You cannot change the session ID during runtime.
This section is a brief example of how to run multiple front and back-ends on multiple computers. Examples are provided for DIS and HLA. For both protocols, assume the configuration in Figure 4-4. This configuration has two front-ends and three back- ends. Each is on a different computer. Assume that they are all running in the same session.
Front-ends
1 2
Back-ends
3 4 5
Figure 4-4. VR-Forces multicomputer configuration
As an alternative to starting individual front-ends and back-ends from the command line and specifying their protocol information in the command line, you can use vrfLauncher to start the front-ends and back-ends. Be sure to specify unique site and application numbers in vrfLauncher. For details about vrfLauncher command syntax, please see “Command-line Options for vrfLauncher,” on page 5-14.
In a DIS exercise, you typically specify a port so that the exercise traffic is isolated from other network traffic. Each front-end and back-end must have a unique site:application ID.
Run VR-Forces on each PC using the following commands:
PC 1:
vrfGui -s 1 -a 3000 --dis -P 1234
PC 2:
vrfGui -s 1 -a 3001 --dis -P 1234
vrfSimDIS | -s | 1 | -a | 3002 | -P | 1234 |
vrfSimDIS | -s | 1 | -a | 3003 | -P | 1234 |
vrfSimDIS | -s | 1 | -a | 3004 | -P | 1234 |
PC 3:
PC 4:
PC 5:
In an HLA exercise, you could simply specify the site:application ID and use default values to specify the HLA configuration parameters. Specification of the site:applica- tion ID is identical to that in DIS. For this example, we use HLA 1.3 and specify a FOM Mapper other than the default (RPR FOM 1).
Run VR-Forces on each PC using the following commands:
PC 1:
vrfGui -s 1 -a 3000 --hla -x MAK-RPR-2.0
--rprFomVersion 2.0017 -F MAK-RPR2-1-1.fed
PC 2:
vrfGui -s 1 -a 3001 --hla -x MAK-RPR-2.0
--rprFomVersion 2.0017 -F MAK-RPR2-1-1.fed
PC 3:
vrfSimHLA13 -s 1 -a 3002 -x MAK-RPR-2.0
--rprFomVersion 2.0017 -F MAK-RPR2-1-1.fed
PC 4:
vrfSimHLA13 -s 1 -a 3003 -x MAK-RPR-2.0
--rprFomVersion 2.0017 -F MAK-RPR2-1-1.fed
PC 5:
vrfSimHLA13 -s 1 -a 3004 -x MAK-RPR-2.0
--rprFomVersion 2.0017 -F MAK-RPR2-1-1.fed
Simulation control toolbars:
Simulation Control toolbar. Allows you to start, pause, and rewind a scenario.
Simulation Selection toolbar. Displays site and application numbers of multiple back-ends, if present.
Simulation Time toolbar. Displays the elapsed simulation time.
Simulation Time Scale toolbar. Allows you to control the speed at which the simulation runs.
Application panels. Dockable panels that provide information and let you manage the observer.
Object creation palettes. Palettes for creating simulation objects, tactical graphics, and props.
Menus Toolbars
Panels Palettes
Terrain and object display
Figure 4-5. VR-Forces window and toolbars (2D)
You can view the terrain in 2D (Figure 4-5), 3D (Figure 4-6), and exaggerated reality (XR) (Figure 4-7) modes.
Starting VR-Forces — The VR-Forces Window
Figure 4-6. VR-Forces window (3D)
Figure 4-7. VR-Forces window (XR)
You can undock toolbars and panels and display them anyplace on your desktop. You can hide any toolbar that you do not want to be visible. (For details, please see Chapter 78, GUI Controls, Layouts, and Behaviors.)
You can open windows with a 2D view or 3D view. Once a window is open, you can change the view by changing the observer mode.
Opening a secondary window is not the same thing as running a second instance of the front-end. When you close a front-end, all secondary windows associated with it are also closed.
To open a new window, choose File New Stealth Window or File New Plan View Window.
You can also open a new window by opening an inset view. For details, please see “Inset Views,” on page 51-2.
You can print the VR-Forces display to any printer configured on your computer. None of the GUI controls or tabs get printed.
To print the VR-Forces display:
Choose File Print. The Print dialog box opens.
Select a printer.
Click Print.
A front-end can be joined to a session or not joined. When a front-end is not joined to a session, it cannot create, load, or manage a scenario. It can only load a terrain and function as a viewer. You can tell a front-end’s session status by the availability of Join Session and Resign Session commands on the File menu.
By default, when you start a front-end it automatically tries to join a session. If there is no session running, it polls the network until one becomes available and then automat- ically joins it. Once a front-end is joined to a session, you can manually resign from and rejoin it.
When a front-end joins a session, its behavior depends on the session options set in the Application Settings dialog box, Session Options page. The options are:
Ask to join the session.
Always join the session with the session database.
Always join the session with whatever database is currently loaded.
!
!
If you do not load the terrain specified by the scenario, it is possible that visual and simulation terrains will not be synchronized.
Starting VR-Forces — Managing a Front-end’s Session Connection
When you join a session, all menu commands related to scenario management are enabled. If a scenario is loaded in the session, the terrain is automatically loaded in the joining front-end.
To join a session:
Choose File Join Session. If VR-Forces is configured to always join a session with the session database, the front-end loads the session database and joins the session. If VR-Forces is not configured to automatically use the session database, the Join Session dialog box opens (Figure 4-8). If a scenario is running, its details are listed.
Scenario running No scenario running
If a scenario is running, you can specify that you want to load an alternate terrain:
Select the Join Using Alternate Terrain check box.
Click Join. An Open Database dialog box opens.
Select the terrain that you want to load.
Click Open. The terrain is loaded and the front-end joins the session.
!
!
If you join a session using an alternate terrain, the front-end (visual) and back-end (simulation) terrains might not be synchronized.
Click Join. The front-end joins the session.
When you resign from a session, all menu commands related to scenario management are disabled. If you have a scenario loaded, the terrain is closed.
To resign from a session, choose File Resign From Session.
You can configure the display of session-related messages and whether or not the front- end tries to join a session or open a terrain database automatically at startup.
To configure sessions:
Choose Settings Application. The Application Settings dialog box opens.
Select the options that you want to enable, as follows:
Automatically Join Session. If selected, when the front-end starts, automatically join a session if it is available. If cleared, the front-end does not join a session and does not prompt you to do so.
Table 4-1: Join session and open session database interaction
Automati- cally Join Session
Open Ses- sion Data- base without
Joining Result
Automati- cally Join Session
Open Ses- sion Data- base without
Joining Result
At startup, VR-Forces joins the session, loads the terrain, and you have full control of objects and scenario actions.
At startup, VR-Forces loads the terrain database. You have no ability to create published objects or control the scenario. (You can create local tactical graphics.) If you clear this check box after the terrain loads, it remains loaded.
If you resign from a session, the terrain database stays open and you cannot create published objects or control the scenario. (You can create local tactical graphics.)
If, after starting VR-Forces, you select Automatically Open Session Database without Joining Session and a session is open, the terrain is loaded.
Starting VR-Forces — Using HLA Time Management
Join Session Options. You can select one of the following options for joining a session:
Ask to Join Session. Provides session data (Figure 4-8) and prompts you to approve whenever you join a session.
Show Database Correlation Warning Dialogs. If enabled, VR-Forces displays a warning if the terrain in the front-end might not correlate with the terrain loaded in the back-end.
Show Scenario Startup Dialog. Enable if you want to be prompted when a new session starts.
Click Close.
The main reasons why you might want to enable time management for VR-Forces are to run VR-Forces as part of a wider federation that is using time management or to synchronize multiple VR-Forces back-ends. Without time management, multiple back- ends can stay synchronized only if they all are able to maintain the same frame rate.
However, if they cannot do so, they will no longer have a shared concept of simulation time and will become unsynchronized. By using time management services, multiple back-ends can be configured to run in lock-step with respect to simulation time, ensuring that events will always happen in the same order.
i VR-Forces supports time management in the back-end only.
For details about enabling time management, please see “Configuring Time Manage- ment for HLA Exercises,” on page 4-18.
Starting VR-Forces — Using HLA Time Management
VR-Forces simulation time is not the same as HLA federation time. It is the elapsed time within a scenario (the time displayed in the Simulation Time toolbar). When you first start a simulation, federation time and simulation time may be similar. However, if you rewind a time-managed simulation, the discrepancy between the two time streams will increase. This should not have any effect on running and rewinding scenarios. As long as all the back-ends start from the same simulation state when you begin a simula- tion, they will be correctly synchronized (against federation time) as the simulation progresses.
Time management is enabled at the application level, not the scenario level. Scenarios created without use of time management work in time-managed mode. No time management-specific information is saved as part of a scenario.
If you enable time management in the back-end, then whenever you create or load a scenario that specifies a fixed-frame mode (that is, the frame-mode parameter in the scenario file is set to either fixed-frame best effort or fixed-frame-run-to-complete), the back-end will become a regulating and constrained federate. It will remain in this state until the scenario is closed.
A time-managed back-end advances simulation time at a rate that is a function of the frame-mode specified in the scenario it is executing. If the frame-mode is fixed-frame, then it tries to advance simulation time at a rate approximating real time. However, if the back-end has a heavy simulation load, or another time-constrained federate is advancing at a relatively slower rate, the back-end may not achieve this rate. If the frame- mode is fixed-frame-run-to-complete, the back-end tries to advance simulation time as fast as possible, independent of wall-clock time.
To use time management in VR-Forces, your RTI must be properly configured to support this service. If you are using the MAK RTI, set the RTI_useRtiExec and RTI_timeMgmt parameters to 1. When you start the federation, you must run the rtiexec.
If you are using another RTI, please consult its documentation for configuration instructions.
Starting VR-Forces — Opening a Terrain Database
To enable time management in the back-end, use one of the following methods:
Set runInTimeManagementMode to 1 in vrfSim.mtl.
Start the back-end with the --timeManagement command-line option. For example, to start the back-end in time management mode using HLA 1.3, the sample FED file configured for use with time management, and the federation name MAK-RPR1-TimeManagement-1-1:
vrfSimHLAprotocol -s 1 -a 3001 --timeManagement
-F MAK-RPR1-TimeManagement-1-1.fed -x MAK-RPR1-TimeMan- agement-1-1
If a scenario is configured with frame-mode set to variable-frame, the back- end will not become time regulating or constrained. It will print a warning to the console and run without time management enabled.
If you are using multiple front-ends, when you load or create a scenario, the front-end on which you issue the command loads the correct terrain database. The other front- ends prompt you to load the terrain. However, you can choose to load a different terrain. Also, if you want to use the front-end as a viewer, you can manually load a terrain database. (For a brief description of the databases supplied with VR-Forces, please see “Terrain Databases Provided with VR-Forces,” on page 53-19.)
You can only “open” terrains in MTF format. To open any other terrain format, you must compose a terrain, as described in Chapter 55, Composing Terrains, or use an earth file, as described in Chapter 56, Paged and Streaming Terrains.
The first time you load a terrain (including the terrains supplied with VR-Forces), VR- Forces caches textures in its fast load format. This is a slow process. However, thereafter the terrain will load quickly. If you want to avoid runtime caching, you can preprocess the terrain with the medfTool before you load it. (For details about the medfTool, please see “Compressing Model Files,” on page 83-27.) If you want to disable runtime caching, you can do so as described in “Configuring File Caching,” on page 61-2.
!
!
It is possible to open a terrain without having a scenario loaded. In such cases you can create tactical graphics and add props, but you cannot create simulation objects. To create and manipulate simulation objects, you must load or create a scenario.
Starting VR-Forces — Opening a Terrain Database
In the VR-Forces window, choose File Open Terrain. The Open Terrain dialog box opens.
Select the terrain that you want to open.
Click Open. The database is displayed in the VR-Forces window (Figure 4-9).
Figure 4-9. VR-Forces window with a database loaded
If you load a terrain database while one is currently loaded, VR-Forces closes the current database and then opens the new one.
Paged terrains might not be visible when loaded in Plan View mode. To see the terrain, press e to zoom in. This problem potentially exists for all paged terrains whose page-in distance is less than the default observer distance in Plan View mode.
Some MetaFlight terrains do not display in the 2D view when first loaded. To see the terrain, change to a 3D view mode, and press the space bar (center view on terrain) to move the eyepoint to the terrain location. After this, the terrain can be viewed in the 2D view.
You can load a terrain database at startup by specifying it on the command line. If you start VR-Forces while a session is running, it can load the appropriate terrain database automatically. For details, please see “Configuring Session Messages and Join at Startup,” on page 4-16.
To load a terrain database when you start VR-Forces, use the -T command line option.
vrfSimprotocol -s 1 -a 3001 -T “../userData/terrains/myDa- tabase.mtf”
where protocol is DIS, HLA13, HLA1516, or HLA1516e.
To close a terrain, use one of the following methods:
Choose File Close Terrain.
Choose File New Terrain.
Open a different terrain.
VR-Forces has the following types of settings:
Independent, or display, settings are the individual settings managed on the Settings menu and the pages of the Display Settings dialog box. Changing an inde- pendent setting, such as enabling track histories or wireframe mode, does not affect other settings.
Independent settings are categorized as being global settings or observer-specific settings. Global settings apply regardless of the observer mode. Observer-specific settings can be different for each observer mode. For more information, please see “Global Settings and Observer-Specific Settings,” on page 4-24.
Dependent settings are the schemas, model definitions, element definitions, and object type mappings that collectively determine how simulation objects and objects are modeled in the scene. Changing a dependent setting, such as a model definition may affect settings that depend on it, such as an entity definition.
Starting VR-Forces — Managing VR-Forces Settings
VR-Forces manages settings as follows:
As you make changes to settings during a session, it saves the changes, except for model definitions, element definitions, and simulation object type mappings.
It remembers the settings in effect when you exit and uses them as the default settings in your next session.
During any particular session, you can revert to the default settings.
You can save the current settings to a file.
You can import saved settings.
You can restore settings to those that were in effect when VR-Forces was first installed (factory settings).
Dependent settings have two additional options that independent settings do not have:
You can save or restore some types of settings by specific setting.
You can merge settings from a file into the current settings.
The procedures for saving and restoring settings are the same regardless of the types of settings. You start the process by clicking a button on a settings dialog box page. The way that VR-Forces saves and restores depends on the type of setting, as follows:
When you initiate a save or restore operation on independent settings, it saves or restores all of the settings on the dialog box page from which you started the save or restore. If you have changed a setting on another page, it is not affected.
When you initiate a restore operation on dependent settings, related settings may also be restored. VR-Forces displays a message listing the settings that will be restored.
When you save dependent settings, you either export all settings of a given type or selected settings. For details, please see relevant sections in Chapter 82, Mapping Models and Effects.
(Figure 4-10) illustrates the common settings management buttons. (The Visual Model Editors dialog box has some additional buttons. They are explained in Chapter 82, Mapping Models and Effects.)
Revert to the default settings. Override any changes made to settings during this session.
Restore the factory settings. Change settings to the settings used when VR- Forces was installed. (The factory settings and default settings may be different.)
Import settings from a file. Replace the current settings with those stored in the selected file.
Merge in settings from a file. Merging works as follows:
Saved settings that do not have a match in the current settings are added.
Saved settings replace matching settings.
Current settings that are not replaced (that is, for which there is no match in the saved settings) remain valid.
Figure 4-11 illustrates how merged settings work. Setting A in the saved settings has no match in current settings, so it is added to the merged settings. Current
settings B2 and C2 are replaced with saved settings B1 and C1. Current setting D has no match in saved settings, so it is retained in the merged settings.
Saved Settings Current Settings Merged Settings
Setting A Setting B1 Setting C1
Setting B2 Setting C2 Setting D
Setting A Setting B1 Setting C1 Setting D
Export all settings to a file. Save the current settings to the selected file.
Save the selected setting to a file.
VR-Forces saves model definition and element definitions to settings to
./appData/definition. Other settings get saved to ./appData/settings/vrfGui.
If you load an alternative settings file at startup, it is treated like an imported settings file.
If your simulation is using several front-ends and back-ends on multiple computers, you may want to use the same settings across all of them, particularly if you have added model definitions and mappings to the factory settings. To synchronize settings, copy the data directories (./appData, ./data, and ./userData) from the computer on which you have updated them to the computers on which the other front-ends and back-ends are installed. Then import the settings into any Settings page that you customized on the source VR-Forces machine.
Starting VR-Forces — Exiting VR-Forces
VR-Forces has two types of independent settings – global settings and observer-specific settings.
Global settings affect the display regardless of which observer mode you are using. Global settings include simulation object labels, tactical graphics, and cockpit displays. The settings on the Settings menu are all global settings.
Observer-specific settings can be different for each observer mode. In fact, given a similar projection and model set, it is the different settings that distinguish one observer mode from another. For example, one difference between Stealth observer mode and Out-the-Window observer mode is that Stealth mode has tactical smoke enabled and Out-the-Window mode has it disabled.
When you exit VR-Forces from the GUI, all GUI windows close. In combined mode, the simulation engine also closes. If you are not running in combined mode, you must also close all simulation engines.
To exit the VR-Forces GUI, choose File Exit.
To exit the simulation engine, type q and press Enter.
A simulation connection specifies the connection parameters for a DIS or HLA simula- tion connection. VR-Forces comes with the following connection configurations:
DIS (7) localhost (for use when disconnected from a network or if you do not want to interact with network traffic).
DIS (7).
HLA 1.3 RPR FOM 2.0 with MAK extensions.
HLA 1516 Evolved RPR FOM 2.0 with MAK extensions.
You can edit the supplied configurations or add your own connection configurations that use, for example, a different DIS port or your own FOM Mapper.
Simulation connection configurations are maintained in the Simulation Connections Configuration dialog box. This dialog box opens automatically when you start VR- Forces, unless you choose a configuration as the default connection for auto connec- tion. If Auto Connect is enabled and you want to change the connection, you can open the dialog box from the Tools menu.
To open the Simulation Connections Configuration dialog box, on the Windows Start menu, choose MAK Technologies VR-Forces 4.5 Tools Configure Connections.
To start the vrfLauncher on Linux (or from the Windows command line), in a console window, enter the following command:
vrfLauncher options
For descriptions of the vrfLauncher command-line options, please see “Command-line Options for vrfLauncher,” on page 5-14.
When you add a new simulation connection, it has the default values for the protocol that you select. You can then customize it to meet your needs. You can also add new connections by copying an existing connection.
To add a simulation connection:
On the Windows Start menu, choose MAK Technologies VR-Forces 4.5 Tools
Configure Connections. The Simulation Connections Configuration dialog box opens (Figure 4-12).
Figure 4-12. Simulation Connections Configuration dialog box
Click the Add Connection button ( ). The Create Connection dialog box opens (Figure 4-13).
In the Connection Name box, type a name for the connection.
Select a protocol from the Protocol list.
Click OK.
The connection is added to the list in the Simulation Connections Configuration dialog box.
Select the new connection in the list.
Edit the parameters as desired. They are described in “Simulation Connection Parameters,” on page 4-28.
You can create a new simulation connection by copying an existing connection.
To copy a simulation connection:
On the Windows Start menu, choose MAK Technologies VR-Forces 4.5 Tools
Configure Connections. The Simulation Connections Configuration dialog box opens (Figure 4-12).
Click the Copy Connection button ( ). The Copy Connection dialog box opens.
Accept the default name or type a new name.
Click OK.
Change the connection settings as desired.
To edit a simulation connection:
On the Windows Start menu, choose MAK Technologies VR-Forces 4.5 Tools
Configure Connections. The Simulation Connections Configuration dialog box opens (Figure 4-12).
In the list of connections, select the connection that you want to edit.
Edit the parameters as desired. They are described in “Simulation Connection Parameters,” on page 4-28.
The HLA and DIS simulation connection parameters are equivalent to command-line options for DIS and HLA. Table 4-2 cross references the parameters to their descrip- tions in Chapter 5, Command-line Options.
Table 4-2: Connection configuration parameters
Command-line
Parameter
DIS
equivalent Description
Port -P Specifies the DIS port. “Specifying the Port Number,” on page 5-20.
Exercise ID -x Specifies the DIS exercise ID. “Specifying the Exercise ID,” on page 5-21.
Back-end Site Number
Front-end Site Number
Back-end Applica- tion Number
Front-end Appli- cation Number
-s Specifies the site ID. These values can be the same or different. It is entirely arbi- trary. “Specifying the Site ID and Applica- tion Number,” on page 5-15.
-a Specifies the application number. The default front-end application number is created by adding 100 to the back-end application number. “Specifying the Site ID and Application Number,” on
DIS Version --disVersion Specifies the DIS version: 4, 5, or 6.
Default: 6. “Specifying the DIS Version,” on page 5-21.
Network Inter- face Address
Destination Address
Multicast Addresses
--deviceAddress Specifies the address of the network card
to use for UDP traffic.
-A Specifies a specific destination address (point-to-point). “Specifying Point-to-Point or Multicast Operation,” on page 5-20.
-S Specifies one or more multicast addresses. “Specifying Point-to-Point or Multicast Operation,” on page 5-20.
Send Buffer Size --sendBufferSize Specifies the send buffer size. Default: -1.
Receive Buffer Size
--recvBufferSize Specifies the receive buffer size.
Multicast TTL --mcastTtl Specifies the multicast time-to-live.
Default: -1.
Use Asynchro- nous I/O
--useAsyncIO Use asynchronous I/O. Default: False.
Use Absolute Time Stamps
--useAbsolute- TimeStamps
Specifies use of absolute time stamps instead of relative time stamps.
Table 4-2: Connection configuration parameters
Parameter
Command-line equivalent
Description
Parameter
Command-line equivalent
Description
!
!
If you select Use Absolute Time Stamps, it is your responsibility to ensure that the time clocks of exercise participants are synchronized. If they are not synchronized, VR-Forces may not work properly.
HLA
HLA
Network Inter- face Address
--deviceAddress The IP address of the host computer.
Federation Name -x Specifies the name of the federation execution. “Specifying the Federation Execution,” on page 5-17.
FED File Name -F Specifies the FED file to use. “Specifying the FED File,” on page 5-18.
Back-end Site Number
Front-end Site Number
Back-end Applica- tion Number
Front-end Appli- cation Number
-s Specifies the site ID. These values can be the same or different. It is entirely arbi- trary. “Specifying the Site ID and Applica- tion Number,” on page 5-15.
-a Specifies the application number. The default front-end application number is created by adding 100 to the back-end application number. “Specifying the Site ID and Application Number,” on
RPR FOM Version --rprFomVersion “Specifying the RPR FOM Version,” on
FOM Mapper Library
-f Specifies the VR-Link FOM Mapper to use. “Specifying a FOM Mapper,” on page 5-18.
Initialization String
--fomMapperInit- Data
Specifies initialization data required by the FOM Mapper, if any. “Specifying FOM Mapper Initialization Data,” on page 5-19.
Local Settings Designator
-s Specifies a string that is passed to the RTI during federate connect when using HLA Evolved. It is usually used to provide addi- tional RTI configuration, but every RTI uses it differently. Please consult your RTI documentation for proper usage.
FOM Modules --fomModules Specifies FOM Modules. (HLA Evolved
only.)
Ignore Advisories --useAdvisories Specifies whether or not to use HLA advi-
sories.
Table 4-2: Connection configuration parameters
Parameter
Command-line equivalent
Description
Parameter
Command-line equivalent
Description
Use Absolute Time Stamps
--useAbsolute- TimeStamps
Specifies use of absolute time stamps instead of relative time stamps.
!
!
If you select Use Absolute Time Stamps, it is your responsibility to ensure that the time clocks of exercise participants are synchronized. If they are not synchronized, VR-Forces may not work properly.
To delete a simulation connection:
Open the Simulation Connections Configuration dialog box, as described in “Opening the Simulation Connections Configuration Dialog Box,” on page 4-25.
In the list of connections, select the connection that you want to delete.
Click the Delete button ( ). A confirmation prompt opens.
Click Yes.
If you know that you will usually or always want to use the same simulation connec- tion, you can set up Auto Connect and you will not have to select a connection every time you start VR-Forces.
To configure Auto Connect:
Choose MAK Technologies VR-Forces 4.5 Tools Configure Connections. The Simulation Connections Configuration dialog box opens (Figure 4-12).
In the list of connections, select the connection that you want to use every time you start VR-Forces.
Click Set as Auto Connect. A star is displayed next to the selected connection.
To disable Auto Connect:
Choose MAK Technologies VR-Forces 4.5 Tools Configure Connections. The Simulation Connections Configuration dialog box opens (Figure 4-12).
In the list of connections, select the connection that is configured for auto connect.
Click Set as Auto Connect. Auto connect is disabled and the star is removed from next to the connection.
You can display connection information while you are running VR-Forces. This may be useful for diagnostic purposes.
To view connection information, choose Settings Connection Information. The Connection Information dialog box opens (Figure 4-14).
Figure 4-14. Connection Information dialog box
One way to extend the functionality of VR-Forces is by loading plug-ins that have been written for it by MAK or other software vendors. You can manage which plug-ins get loaded when VR-Forces starts up. You can also view information about the plug-ins that have been loaded.
Plug-ins are implemented as one or more dynamic linked libraries (DLL or SO files). The DLLs can be release or debug, for vrfSim or vrfGui, for Windows or Linux, and for a specific protocol or protocol-independent. Each association of an application, plat- form, build type, and transport type is called a configuration. The Plug-ins Editor lets you specify the DLLs to use for each of the desired configurations.
Changes to plug-in configurations do not take effect until the next time you start the affected VR-Forces application.
You can specify which plug-ins to load in either of the following ways:
In the Plug-ins dialog box, specify the plug-ins to load the next time VR-Forces starts.
In the Simulation Connections Configuration dialog box, specify the plug-ins to load at startup.
The Plug-ins dialog box lets you specify the plug-ins that will be loaded the next time that you start VR-Forces.
To specify that a plug-in be loaded or not loaded in the Plug-ins dialog box:
Choose Settings Plug-ins. The Plug-ins dialog box opens.
Select the Plug-ins Editor page (Figure 4-15).
In the list of plug-ins at the top of the page, select the one that you want to edit. The configurations for that plug-in are listed in the window.
Select or clear the Load Plug-in check box.
You can select the plug-ins that you want to load at startup.
To specify the plug-ins to load in the simulation connections configuration:
Start VR-Forces using the VR-Forces Launcher, as described in “Starting VR- Forces from the VR-Forces Launcher,” on page 4-3. The Simulation Connections Configuration dialog box opens (Figure 4-1).
Click Plug-ins. The Plug-ins Selection dialog box opens (Figure 4-16). The dialog box lists all of the plug-ins that are configured for VR-Forces. If a plug-in has previ- ously been selected for loading, in this dialog box or in the Plug-ins Editor, it is checked.
Select the check boxes for the plug-ins that you want to load. Clear the check boxes for any plug-ins that you do not want to load.
Click OK. The plug-in configuration applies to all of the startup configurations.
When you add a plug-in, VR-Forces creates an XML file (in ./appData/plugins) that contains all of the information VR-Forces needs to load the plug-in. New plug-ins are added with entries for each of the configurations (application, platform, build type, transport). After you add a plug-in, you must specify the DLLs for each configuration that you want to support.
To add a plug-in:
Choose Settings Plug-ins. The Plug-ins dialog box opens (Figure 4-15).
Select the Plug-ins Editor page.
Click the Add button ( ) at the upper right corner of the page (#1 in Figure 4-17). The New Plug-in dialog box opens.
Type a name for the plug-in.
Click OK. The plug-in is added to the Plug-ins list. It has configurations for each of the combinations of application, platform, build type, and transport (Figure
4-17).
1 2
3
4
Specify the DLL for each configuration that you want to support, as described in “Specifying the DLLs for a Plug-in,” on page 4-35.
To specify the DLL for a plug-in configuration:
Choose Settings Plug-ins. The Plug-ins dialog box opens (Figure 4-15).
Select the Plug-ins Editor page (Figure 4-18).
In the list of plug-ins at the top of the page, select the one that you want to edit.
Click the Plug-in Library column for the configuration that you want to edit. The Select Plugin dialog box opens.
Select the DLL that you want to load for this configuration.
Click Open. The value is changed.
You can remove the DLL assignment for a plug-in configuration without removing the configuration.
To remove the DLL assignment for a plug-in:
Choose Settings Plug-ins. The Plug-ins dialog box opens (Figure 4-15).
Select the Plug-ins Editor page.
Select the configuration whose DLL assignment you want to remove.
Click the Erase button ( ).
To add a plug-in configuration:
Choose Settings Plug-ins. The Plug-ins dialog box opens (Figure 4-15).
Select the Plug-ins Editor page.
In the list of plug-ins at the top of the page, select the one that you want to edit.
Click the Add button ( ) above the list of configurations (#3 in Figure 4-17). The Add Plug-in dialog box opens (Figure 4-19).
For each parameter (Application, Platform, Build Type, and Transport), select a value from the list.
Click OK. The configuration is added to the list.
Specify a DLL for the configuration, as described in “Specifying the DLLs for a Plug-in,” on page 4-35.
To delete a plug-in configuration:
Choose Settings Plug-ins. The Plug-ins dialog box opens (Figure 4-15).
Select the Plug-ins Editor page.
In the list of plug-ins at the top of the page, select the one that you want to edit.
Select the configuration that you want to delete.
Click the Delete button ( ) that is above the list of configurations (#4 in Figure 4-17).
When you delete a plug-in, you delete the XML configuration file in ./appData/plugins
that specifies the plug-in configurations and whether or not to load it.
To delete a plug-in:
Choose Settings Plug-ins. The Plug-ins dialog box opens (Figure 4-15).
Select the Plug-ins Editor page.
In the list of plug-ins at the top of the page, select the one that you want to delete.
Click the Delete button ( ) to the right of the plug-ins list (#2 in Figure 4-17).
You can view a list of the plug-ins that are loaded when you start up VR-Forces. Plug- ins may include a description that you can also view.
To view the details of loaded plug-ins:
Choose Settings Plug-ins. The Plug-ins dialog box opens (Figure 4-20).
Select the Plug-ins Loaded page (Figure 4-20).
To view details about a plug-in, select it in the list.
Starting VR-Forces — The VR-Forces Log Files
On Windows, VR-Forces creates two log files, vrfSim.log and vrfGui.log. Both log files are written to the directory from which you run VR-Forces.
On Linux, in combined mode, VR-Forces automatically creates a log file, vrfSim.log for back-end output. Front-end output is sent to the console. If you want to view back-end output, open a second console window, and do tail -f vrfSim.log. If you want to send front-end output to log files, or if you are running in separate mode and want to create a log file for either the front-end or back-end, you need to redirect your output to a file, for example:
vrfGui > vrfGui.log
VR-Forces has command-line options for vrfGui and vrfSim.
Command-Line Options for vrfGui 5-3
Command-line Options for vrfSim 5-9
Command-line Options for vrfLauncher 5-14
Running in Combined Mode from the Command Line 5-15
Using the -- Command-line Argument 5-15
Protocol-Independent Command-line Options 5-15
Specifying the Site ID and Application Number 5-15
Specifying the Language to Use in the GUI 5-16
Setting the Notification Level 5-16
Command-line Options for HLA Federations 5-17
Specifying the Federation Execution 5-17
Specifying the RPR FOM Version 5-18
Specifying the RPR FOM Revision 5-18
Specifying FOM Mapper Initialization Data 5-19
Specifying a FED File That is Appropriate for the FOM Mapper 5-19
Command-line Options for DIS Exercises 5-20
Specifying the Port Number 5-20
Specifying Point-to-Point or Multicast Operation 5-20
Specifying the Multicast Time-to-Live 5-20
Command-line Options
Specifying the Exercise ID 5-21
Specifying the DIS Version 5-21
Table 5-1 lists the command line options for vrfGui.
Table 5-1: vrfGui command-line options (Sheet 1 of 7)
(-- | --ignore_rest) Ignore all command-line options after this one. This
option is useful for disabling part of a command line in a script for test purposes so that you do not have to retype all of the command options at a later point.
--alphaBits bits Sets the number of alpha bits (0, 8).
--antiAliasing level Set the anti-aliasing level (0, 2, 4, 8, or 16). Default:
4.
--appDataDir directory Specifies the location of application data.
(-c | --showConsole) Display a console window.
(-C | --autoConnect)
{filename | connector_name}
Automatically connect to the network using the specified connector.
--dataDir directory Specifies the location of the data directory (terrains
--defaultSimulationModel- Set sms
The simulation model set to use as the default when starting up the GUI.
--depthBits bits Sets the depth of graphics to 24 bits or 32 bits.
--dis Start in DIS mode, using DIS command-line argu- ments to specify connection parameters. DIS- specific arguments do not have to follow --dis; they can be in any order.
--disableDynamicTerrain Disables the dynamic terrain engine. May slightly
speed up terrain loading and paging.
--dispSetting filename Specifies the display engine configuration to load.
--doNotCheckPluginVersions Do not check the version in a plug-in to make sure it
can load in VR-Forces. A plug-in gets built against a particular version of VR-Forces. Ordinarily, when VR-Forces loads a plug-in, it checks to be sure it was created with that version of VR-Forces. This option prevents that check.
--doNotLoadVrfPlugins Prevents loading of plug-ins in the ./plugins direc-
tory.
(-e | --extraArgs) string Allows you to send arbitrary strings to the initializer,
which can be queried for by plug-ins. This option works around the restriction on adding new command-line arguments.
--enableLogFileTimestamps Print a timestamp for each line in a log file.
--enableVSync Turns on VSync.
--entDispSetting filename Specifies the entity display setting to load.
--entityDefsDir directory Loads the .hier and .leaf files in the specified direc-
tory.
--envSetting filename Specifies the environment configuration file to load.
(-E | --entTypeMap) filename Load the specified object type mapping file. The file
extension determines the type of mapping.
--factoryRootDir Set the root directory used to restore settings to factory defaults.
--fileTransporterReceive- Port port
Port for the file transporter. This is the port used to receive order of battle and plan files.
--forceTextShaping Force all text to use HarfBuzz shaping. Use this
option if you need support for right-to-left languages. It may affect performance.
--fowPerspective force Shows the ground truth and spot reports perspec-
tive of the specified force, where force can be Friendly, Opposing, Neutral, or None. Default: None.
--fullScreen Start with the window in full screen mode.
--frameRate rate If rate is 0, the frame rate is variable. Otherwise,
specifies a fixed frame rate for rendering.
(-G | --locale) language Specifies the locale (for localization).
--gui filename Specify a GUI configuration file. This file specifies the layout of menus, toolbars, and dialog box pages. A simple filename assumes
./appdata/settings/vrfGui. A relative filename is from the ./bin directory. A full path is used as is.
(-h | --help) Display command-line usage information.
--highestPriority Changes the priority of the application and the main
render thread to the highest available priority. This command may starve other processes.
--hla13 Start in HLA 1.3 mode, using HLA command-line arguments to specify connection parameters. HLA- specific arguments do not have to follow --hla13; they can be in any order.
--hla1516 Start in HLA 1516 mode, using HLA command-line arguments to specify connection parameters. HLA- specific arguments do not have to follow
--hla1516; they can be in any order.
--hla1516e Start in HLA Evolved mode, using HLA command- line arguments to specify connection parameters. HLA-specific arguments do not have to follow
--hla1516e; they can be in any order.
(-I | --unbatchedRendering) Disables instance rendering. Default: Enabled.
(-K | --disableKDTrees) Disable creation of KD trees for intersections.
(-l | --logFileName)
filename
(-L | --loadObservers)
filename
--layoutSettingsFile
filename
Specifies the log file name.
Loads the saved observers in the specified file. You can use this command multiple times, for example:
--loadObservers file1 --loadObservers file2
Specifies the GUI layout settings file to use. file- name specifies the base filename. It is prefixed with default_ and the extension .uisx is added. Default: UILayoutSettings.
--loadPlugin filename Specifies a plug-in to load. Accepted multiple times.
The filename can be a DLL or SO or an XML file that specifies the plug-ins to load. The order in which you list multiple plug-ins on the command line does not determine the order in which they are loaded. For details, please see “Managing Plug-ins,” on page 4-31.
--loadSimulationObject- Group group
--mergeEntityTypeMap
{directory | filename}
--mergeHierarchyEntityDef
filename
--mergeHierarchyTactical- GraphicsDef filename
--mergeHierarchyUnitDef
filename
--mergeLeafEntityDef
filename
Creates a new scenario on the simulation object group editing terrain and creates an instance of the simulation object group on that terrain.
Merges all entity type mapping files (*.metx) in a directory or individual entity type mapping files. Can be used multiple times.
Merges the specified .hier file into the default hier- archy (usually loaded from ./appData/definitions.) Merging is additive only. No nodes in a previously loaded hierarchy are replaced.
Merges the specified .hier file into the default hier- archy (usually loaded from ./appData/definitions.) Merging is additive only. No nodes in a previously loaded hierarchy are replaced.
Merges the specified .hier file into the default hier- archy (usually loaded from ./appData/definitions.) Merging is additive only. No nodes in a previously loaded hierarchy are replaced.
Merges the specified leaf file into the default entity element definitions.
--mergeLeafTacticalGraph- icsDef filename
Merges the specified leaf file into the default tactical graphics element definitions.
--mergeLeafUnitDef filename Merges the specified leaf file into the default unit
--mergeModelDefs {directory
| filename}
--mergeTacticalGraphics- TypeMap {directory | filename}
--mergeUnitTypeMap
{directory | filename}
(-n | --notifyLevel)
notify_level
Merges all model definition files (*.ommx) in the specified directory or individual model definition files. Can be used multiple times.
Merges all tactical graphics type mapping files (*.mtgx) in a directory or individual tactical graphics type mapping files. Can be used multiple times.
Merges all unit type mapping files (*.magx) in a directory or individual unit type mapping files. Can be used multiple times.
Specifies the notification level for application messages, where notification_level is a number from 0 through 4. The least verbose message level is 0, the highest is 4. The default is 2. For details, please see “Setting the Notification Level,” on page 5-16.
--noAppDataEntityDefs Do not load the entity element definitions in
--noAppDataTacticalGraph- icsDefs
Do not load the tactical graphics element definitions in ./appData/definitions.
--noAppDataUnitDefs Do not load the unit element definitions in
./appData/definitions.
--noAppDataEntityTypeMap Do not load entity type mappings in ./appData/defi-
nitions.
--noAppDataModelDefs Do not load model definitions in ./appData/defini-
tions.
--noAppDataTacticalGraphic- sTypeMap
Do not load tactical graphics type mappings in
./appData/definitions.
--noAppDataUnitTypeMap Do not load unit type mappings in ./appData/defini-
tions.
--nonVrfObjectsUUIDScheme
scheme
Sets the UUID scheme for non VR-Forces objects. Values are entity-identifier, global-identifier, marking-text. Default: entity-identifier.
(-O | --hasNTPSync) Enables synchronized ocean between different VR-
--plugin filename Load the specified plug-in. Can be used multiple
times.
--pseudoFullScreen Use pseudo full screen for full screen mode. This
may improve performance when using dynamic ocean.
--pvd Start the VR-Forces front-end with only 2D modes available.
(-S | --suppressHatInter- sectOnAttach)
Suppress the periodic HAT intersection when attached. This setting can improve performance if you need to attach the observer to ground vehicles a lot, but do not need to attach to air vehicles.
--scenarioFile filename Specifies a scenario to load.
--stealth Start the VR-Forces front-end with only 3D modes available.
--stencilBits bits Sets the number of stencil bits (0 or 8). Default: 0.
terrain_MTF_file Specifies a terrain (MTF) file to load.
--unplug filename Do not load the specified plug-in. Can be used
--useAbsoluteTimeStamps Enables use of absolute time stamps. Otherwise
uses relative time stamps.
!
!
If you select --useAbsoluteTimeStamps, it is your responsibility to ensure that the time clocks of exercise participants are synchronized. If they are not synchronized, VR-Forces may not work properly.
--useFileCommChannel
channel
--userDataDir directory Specifies the user data directory.
(-v | --version) Display version information and exit.
(-z | --useReverseZBuffer) Specifies use of reverse Z buffering, which may
reduce Z-fighting when viewing the terrain from a distance.
(-Z | --ignoreZoomFor- Disable zoom for SpeedTree LOD.
SpeedtreeLod
HLA Only
These options are available if you specify --hla13,
HLA Only
These options are available if you specify --hla13,
(-a | --appNumber) number Application number.
(-F | --fedFileName)
FOM Mapper library name. FED file name.
--fomMapperInitData data FOM Mapper initialization data.
--fomModules module Specifies an HLA Evolved FOM module. Can be used
(-H | --hostAddressString)
address
Specifies the host address. This is usually the same as the device address.
(-i | --sessionId) ID Specifies the session ID for this instance of the
front-end.
--ignoreAdvisories Enables or disables HLA advisory messages.
--localSettingsDesignator
designator
(-N | --federateName)
federate_name
Specifies a unique name that can be assigned to the federate. No two federates within the same federa- tion can have the same name. If no name is speci- fied, the RTI will automatically assign a unique name for the federate.
Default: VR-Forces. (HLA Evolved only)
(-p | --federateType) type Federate Type can be used to distinguish different
categories of federates, and its only practical use is in save-and-restore.
--rprFomRevision RPR FOM revision for RPR FOM 2.0, draft 17.
version_number
RPR FOM version. (0.5, 0.7, 0.8, 1.0, 2.0006,
(-s | --siteId ID Site ID.
--useGeographicDdm Specifies use of geographic DDM if you are using
(-x | --execName) exec_name Execution name. Default: MAK-RPR-2.0.
These options are available if you specify --dis.
These options are available if you specify --dis.
(-a | --appNumber) number Application number.
(-A | --destAddrString) Destination address.
address
--appIdRange The application ID range for VR-Forces back-ends.
--defaultObjectTimeout Specifies the timeout interval for objects.
--deviceAddress address Specifies the address of the network card to use for
UDP traffic.
--disVersion The DIS version. Default: 7.
--fileTransporterReceive- The port for the file transporter.
Port port
Table 5-1: vrfGui command-line options (Sheet 7 of 7)
Option Description
Option Description
(-H | --hostAddressString)
address
Specifies the host address. This is usually the same as the device address.
(-i | --sessionId) ID Specifies the session ID for this instance of the
--mcastTtl Specifies the multicast time-to-live. Default: -1.
--multicastAddresses Specifies one or more multicast addresses.
(-P | --disPort) port DIS port.
--recvBufferSize size Receive buffer size.
(-s | --siteId ID Site ID.
--sendBufferSize size Send buffer size. Default: -1.
--subnetMask mask Specifies a subnet mask.
--useAsyncIO Use asynchronous I/O. Default: False.
--useIpv6 Use the IPV6 protocol, if available.
(-x | --exerciseId) ID Exercise ID.
Table 5-2 describes the command-line options for vrfSim.
Table 5-2: vrfSim command-line options (Sheet 1 of 5)
Option Description
Option Description
(-a | --appNumber)
application_number
--additionalSystemScriptsDi- rectory directory
Specifies the application number. For details, please see “Specifying the Site ID and Application Number,” on page 5-15.
--appDataDir directory Specifies the location of the appData directory.
--appIdRange lower-upper Specifies a range of application IDs that represent
objects generated by VR-Forces.
(-B | --batchScenarioFile- Name) batch_file
Runs the specified batch file. (For use with one back-end only.) For more information, please see Running in Batch Mode from the Command Line, under “Running VR-Forces in Batch Mode,” on page 7-39.
(-c | --frontEndPID) PID The process ID for the front-end when running in
combined mode.
--countryCodesMappingFile
file_name
(-d | --settingsFile)
file_name
Specifies an alternative file that maps country codes to country names and DIS enumeration values.
Specifies a configuration file to load instead of
vrfSimSettings.xml.
--daemon Starts that back-end as a daemon process (Linux only). If you start vrfSim as a daemon, it does not try to read characters from the console. It forks a background process at startup. It will exit cleanly if it receives a SITGTERM, SIGQUIT, or SIGINT signal.
--dataDir directory Specifies the data directory for the back-end.
--defaultObjectTimeout
timeout
--diGuyAnimationsFile
file_name
--diGuyCharacterDataFile
file_name
Specifies the timeout interval for objects.
Specifies an additional configuration file for DI- Guy animations.
Specifies an additional configuration file for DI- Guy character data.
--disableCallbackQueue Disables all main thread parallel algorithms.
--disableParallelTick Execute all tick code serially.
--doNotLoadVrfPlugins Do not load any VR-Forces plug-ins from the
./plugins directory.
--enableChannel channel Enables a specific channel for the channel-specific
output, even if it is disabled in channelSet- tings.mtl.
--fileNotifyLevel level Notify level in log file to use.
--fullyLoadTerrain For paged terrains, load all pages.
(-h | --help) Displays help information in a console window.
--hostAddressString address The IP address of the host computer. Called
Device Address in the Launcher.
(-i | --sessionId)
session_ID
(-L | --scenarioFileName) "scenario_pathname"
Specifies a session ID. For details, please see “Specifying a Session ID,” on page 4-8.
Loads the specified scenario. The pathname can be absolute or relative from the ./bin directory. Mutually exclusive with the -T option. For details, please see “Loading a Scenario from the Command Line,” on page 7-18.
--loadPlugin plugin_file Specifies one or more plug-ins to load. (Accepted multiple times.)
--logFileName filename Log file to use.
--logFrameRateStatistics Specifies that the back-end should log frame rate
statistics.
--msdlSIDCMappingFile
file_name
(-n | --notifyLevel)
notification_level
--nonVrfObjectsUUIDScheme
scheme
Specifies an alternative file for mapping SIDC codes to DIS enumerations.
Sets the level for messages written to the console or the VR-Forces log file (vrf.log), where notifi- cation_level is a number from 0 through 4. The least verbose message level is 0, the highest is 4. The default is 2. For details, please see “Setting the Notification Level,” on page 5-16.
Sets the UUID scheme for non vrf objects. Values are entity-identifier, global-identifier, marking-text.
--numCallbackThreads threads Number of threads in the callback queue.
--outputLogFile file_name The file to use to write out application output.
(-q | --doNotUseConsole) Specifies that all vrfSim output go to the log file
rather than the console (quiet mode). If you are using a high level of notification, sending output to the console can degrade performance. Running in quiet mode prevents this degradation of perfor- mance. This command only applies to back-ends running on Windows. To create a log file on Linux, redirect the output of vrfSim, for example:
vrfSim > mylog.txt
For more details about log files, please see “The VR-Forces Log Files,” on page 4-38.
(-r | --startInRunMode) Starts the back-end in run mode. If you start the
back-end without specifying a scenario (with -L) or a terrain database (with -T), the back-end starts in pause mode.
(-s | --siteId) site_id Specifies the site ID. For details, please see
“Specifying the Site ID and Application Number,” on page 5-15.
--setMainThreadToHighPrior- ity
Sets the VR-Forces main thread to high priority. When enabled, other threads may be starved if there are insufficient processors available. If running on hardware with limited processor time, this may decrease overall system performance. Windows only.
--simulationModelSet sms Specifies the simulation model set. It must be
declared separately for front-end and back-end even in combined mode.
--startMinimized Minimizes the vrfSim console at startup.
(-T | --terrainDatabase)
terrain_database
Specifies a terrain database to load in the back- end. Mutually exclusive with the -L option. For details, please see “Working with Multiple Back- ends,” on page 3-7 and “Loading a Terrain Data- base at Startup,” on page 4-21.
--targetFrameRate rate Specifies the frame rate above which vrfSim will
yield CPU time to other processes.
--useAbsoluteTimeStamps Enables use of absolute time stamps. Otherwise
uses relative time stamps.
!
!
If you select --useAbsoluteTimeStamps, it is your responsibility to ensure that the time clocks of exercise participants are synchronized. If they are not synchronized, VR-Forces may not work properly.
--userDataDir directory Specifies the user data directory for the back-end.
(-v | --version) version Displays version information.
--waitQueue Turn off main thread participation in parallel algo- rithms.
(-- | --ignore_rest)] Ignore all of the command-line options that are
listed after this argument. This lets you quickly limit the arguments applied if you want to edit a script or batch file without losing the original command line.
HLA Only
HLA Only
(-f | --fomMapperLib)
libname
(-F | --fedFileName)
fedfile_name
FOM Mapper library name. FED file name.
--fomMapperInitData data FOM Mapper initialization data.
--fomModules module Specifies an HLA Evolved FOM module. Can be
--ignoreAdvisories Enables or disables HLA advisory messages.
--mimModule Specifies an HLA Evolved MIM module.
(-N | --federateName)
federate_name
Specifies a unique name that can be assigned to the federate. No two federates within the same federation can have the same name. If no name is specified, the RTI will automatically assign a unique name for the federate.
Default: VR-Forces. (HLA Evolved only)
--noRtiCompilerCheck Disable RTI Compiler version check.
(-p | --federateType) type Federate Type can be used to distinguish different
categories of federates, and its only practical use is in save-and-restore.
--rprFomRevision RPR FOM revision for RPR FOM 2.0, draft 17.
--rprFomVersion
version_number
(-S | --localSettingsDesig- nator) designator
RPR FOM version. (0.5, 0.7, 0.8, 1.0, 2.0006,
Specifies a string that is passed to the RTI during federate connect when using HLA Evolved. It is usually used to provide additional RTI configura- tion, but every RTI uses it differently. Please consult your RTI documentation for proper usage.
--timeManagement Enables time management for the back-end.
(-x | --execName) exec_name Execution name. Default: VR-Link.
DIS Only
DIS Only
(-A | --destAddrString) Destination address.
address
--deviceAddress address Specifies the address of the network card to use for UDP traffic.
--disVersion The DIS version. Default: 7.
--mcastTtl Specifies the multicast time-to-live. Default: -1.
(-S | --multicastAddresses) Specifies one or more multicast addresses.
(-P | --disPort) port DIS port.
--recvBufferSize size Receive buffer size.
--sendBufferSize size Send buffer size. Default: -1.
--subnetMask mask Specifies the subnet mask. VR-Forces can usually
figure out the subnet mask from the IP address. However, if it does not do this correctly, you can explicitly specify the subnet mask.
--suppressSelfReflect Represses self reflection of the DIS exercise
--useAsyncIO Use asynchronous I/O. Default: False.
--useIpv6 Specifies that the DIS exercise connection use IPV6.
(-x | --exerciseId) ID Exercise ID.
Command-line Options — Command-line Options for vrfLauncher
Table 5-3 describes the command-line options for vrfLauncher.
Table 5-3: vrfLauncher command-line options
(-B | --backend) Start vrfLauncher for the back-end only.
(-C | --config) Open the Simulation Connections Configuration
tool.
(-F | --frontend) Start vrfLauncher for the front-end only.
(-G | --locale) locale Specifies the language to use.
--guiArgs Arguments after --guiArgs are passed only to the front-end.
(-h | --help) Displays help information in a console window.
--simArgs Arguments after --simArgs are passed only to the back-end.
--usePredefinedConnec- tion connection
Specify an already defined connection name, such as DIS localhost, so that the vrfLauncher can launch without needing to display the Simulation Connections dialog box.
(-v | --version) Displays version information.
-- Pass all arguments after this to vrfGui and vrfSim, except as modified by F-- or B--.
Special Commands for Arguments that Come After --
F-- Arguments after F-- are passed only to the front- end.
B-- Arguments after B-- are passed only to the back- end.
-debug Appends a “d” to vrfGui or vrfSim to run the debug version. Can only be used following B-- or F--. (Windows only)
!
!
The use of the -- command line option is the opposite of how it is used for other MAK applications.
Command-line Options — Protocol-Independent Command-line Options
If you want to run VR-Forces in combined mode from the command line, there are no command-line arguments for vrfGui or vrfSim to support this. However, you can run vrfLauncher with the --usePredefinedConnection argument and VR-Forces will load the specified connection without displaying the Simulation Connections Configu- ration dialog box. This has the effect of running directly in combined mode from the command line. For example, suppose you want to start in combined mode using the DIS connection. The command would be:
vrfLauncher --usePredefinedConnection DIS
The -- command-line argument is used to send additional command-line arguments to the front-end and back-end. This is the opposite of how this argument is used in other MAK applications.
It has some special sub-arguments that allow you to direct some arguments only to the front-end or back-end. It also has an argument that lets you run vrfGui or vrfSim in debug mode. Figure 5-1 illustrates how these arguments are used.
vrfLauncher --usePredefinedConnection DIS_1 -- -P 3456 F-- -c B-- -q -debug
Use predefined connection DIS_1. 
All arguments after this go to the front-end and back-end unless modified by B-- or F--.
Send -c to front-end (show console).
Send -q to back-end (do not use console) and run vrfSimD.
Figure 5-1. Using the -- command-line argument
This section describes in greater detail some of the most commonly used command-line options that you can use with both DIS and HLA.
Each front-end and back-end must have a unique site ID:application number pair. To specify the site ID, use the -s option. To specify the application number, use the -a option, for example:
The default application number for vrfGui is 3000; for vrfSim it is 3001.
Command-line Options — Protocol-Independent Command-line Options
VR-Forces decides which translation files to use based on the language setting for your computer. However, you can override the language setting with the -G command-line option, for example, the following command sets the language to German:
vrfGui -s 1 -a 3000 -G de --dis
If you use this command-line option, you must have a file named vrf_language_code (for example, vrf_de) in the ./translations directory. For more information, please see “Localizing the Graphical User Interface,” on page 2-10.
You can control the types of messages sent to the console (and log file on a PC) by spec- ifying a notification level.
To specify a notification level, use the -n option, for example:
vrfSimDIS -s 1 -a 3001 -n 1
The notification levels you can specify are:
0 – Only fatal messages are printed.
1 – Warning messages and fatal messages are printed.
2 – Some diagnostic information is printed with warnings and fatal messages.
3 – Verbose information is printed.
4 – Debug information is printed. The default notification level is 2.
The Linux version of VR-Forces does not have a log file. Informational messages are sent to the window from which you start VR-Forces. To capture informational messages, redirect output to a file.
You can load plug-ins from the command line or by specifying them in a configuration file. (For details about creating a configuration file, please see “Managing Plug-ins,” on page 4-31.)
To load a plug-in from the command line, use the --loadPlugin command-line option, for example:
vrfGui -s 1 -a 3000 --loadPlugin pluginA
--loadPlugin pluginB --dis
vrfSimDIS -s 1 -a 3001 --loadPlugin pluginA
--loadPlugin pluginB
!
!
Do not specify the extension of the plug-in (for example, .dll). If the extension is included, the plug-in will not load.
VR-Forces can display a list of the plug-ins that are loaded. For details, please see “Viewing a List of Loaded Plug-ins,” on page 4-37.
By default, VR-Forces uses the MAK-RPR2-1-1.fed file and the MAK-RPR-2.0 federa- tion execution.
To specify the HLA federation execution name, use the -x option, for example:
vrfSimHLA13 -s 1 -a 3001 -x MAK-RPR-2.0
--rprFomVersion 2.0 -F MAK-RPR2-1-1.fed
!
!
If you are using the MAK RTI and are running multiple, concurrent federation executions, you must run the rtiexec. In other words, you cannot use the MAK RTI in lightweight mode if you are running multiple federations. Please see the MAK RTI documentation for details about how to configure it to use the rtiexec.
Command-line Options — Command-line Options for HLA Federations
In combined mode, specifying -F in the command line also applies to the back-end. If you are running a back-end independently and want to specify a FED file name, you must use -F.
To specify a FED file at startup, use the -F option.
VR-Forces has built-in support for the RPR FOM. The default version is 1.0.
You can specify a different RPR FOM version (0.5, 0.7, 0.8, 2.0006, 2.0014, 2.0017, or 2.0). If you specify a different FOM version, you must also specify the correct FED file (with -F).
vrfSimHLA13 -s 1 -a 3001 --rprFomVersion 2.0
-F MAK-RPR2-1-1.fed
Please see VR-Forces Release Notes for a list of the RPR FOM versions supported by your version of VR-Forces.
VR-Forces supports alternative FOMs through the VR-Link FOM Mapper. You can specify which FOM Mapper to use with the -f command-line option:
vrfSimHLA13 -s 1 -a 3001 -x MAK-RPR-2.0
--rprFomVersion 2.0 -F MAK-RPR2-1-1.fed
-f myFomMapper
MAK revises FED files when it discovers errors in how it has previously handled various aspects of the HLA standard. It maintains multiple revisions to ensure compatibility with applications that depend on previous revisions.
To specify the RPR FOM revision, use the --rprFomRevision revision
command-line option, for example:
vrfSimHLA13 -s 1 -a 3001 --rprFomVersion 2.0017
-F MAK-RPR2-1-1.fed --rprFomRevision 2
Some FOM Mappers require initialization data. If you specify a FOM Mapper that requires such data, specify the data with the --fomMapperInitData option:
vrfSimHLA13 -s 1 -a 3001 -x MAK-RPR-2.0
--rprFomVersion 2.0 -F MAK-RPR2-1-1.fed
-f myFomMapper --fomMapperInitData ABC
The string “ABC” is passed to the FOM Mapper creation function in the shared library as an initialization parameter.
!
!
The -f option only tells the application which FOM Mapper to use. It does not ensure that you are using the right FED file for the FOM Mapper. Make sure that you are using a FED file that is consistent with the FOM Mapper you have chosen.
By default VR-Forces uses a FED file called MAK-RPR2-1-1.fed, but you can specify an alternate FED file using the -F option.
The following example instructs the application to use the RPR FOM 2.0, version 17 FOM mapping code, in the federation execution MAK-RPR20017-1-1, with the MAK-RPR20017-1-1.fed file:
vrfSimHLA13 -s 1 -a 3001 --rprFomVersion 2.0017
-x MAK-RPR20017-1-1 -F MAK-RPR20017-1-1.fed
You can enable time management for the back-end from the command line, as follows:
vrfSimHLA13 -s 1 -a 3001 --timeManagement
-F MAK-RPR1-TimeManagement-1-1.fed
-x MAK-RPR1-TimeManagement-1-1
This section describes command-line options that apply only to using VR-Forces with DIS exercises.
By default, VR-Forces listens to port 3000.
To change the port that VR-Forces listens to, use the -P option, for example:
vrfSimDIS -s 1 -a 3001 -P 3500
vrfGui -s 1 -a 3000 --dis -P 3500
You can specify that VR-Forces run in point-to-point mode or multicast.
To specify point-to-point, use the -A option, for example:
vrfSimDIS -s 1 -a 3001 -A 123.123.12.1
To specify multicast, use the -S option, for example:
vrfSimDIS -s 1 -a 3001 -S 233.233.22.3
You can specify more than one multicast address, as follows:
vrfSimDIS -s 1 -a 3001 -S address -S address ...
i The default is broadcast mode.
The multicast time-to-live specifies the number of routers that a message can pass through when PDUs are sent to multicast addresses.
To specify the multicast time-to-live value, use the --mcastTtl option, for example:
vrfSimDIS -s 1 -a 3001 -S address -S address --mcastTtl 3
If you want to use asynchronous I/O for DIS exercises, start VR-Forces with the
--useAsyncIO option. Using asynchronous I/O can help prevent dropped packets and the resulting loss of information. There is no comparable command-line option for HLA. To use asynchronous I/O in HLA, you set a RID file parameter.
Command-line Options — Command-line Options for DIS Exercises
To set the VR-Forces exercise ID, use the -x option, for example:
vrfSimDIS -s 1 -a 3001 -x 6
To specify the DIS version, use the --disVersion command-line options, for example:
vrfSimDIS -s 1 -a 3001 --disVersion 6
Please see VR-Forces Release Notes for a list of supported versions.
This chapter explains how you can view performance statistics for the front-end and back-end and how you can optimize GUI performance.
Optimizing Simulation Engine Performance 6-3
Optimizing Front-End Performance 6-4
Monitoring the Back-end Frame Rate 6-5
Displaying Performance Statistics 6-6
Displaying the VR-Forces Function Profiler 6-8
Filtering Simulation Objects Using Interest Management 6-8
Enabling Interest Management 6-9
Configuring Interest Management 6-9
Clearing the Model Instancing Cache 6-11
Miscellaneous Performance Configuration Options 6-12
Limiting Use of Spot Reports 6-12
Using Asynchronous I/O for DIS Exercises 6-12
Using Incremental Compiling with Streamed Data 6-12
Specifying the Tick Rate for Components 6-13
Tuning the Network Interface 6-14
Tuning the State Repository Tick Rate 6-14
Configuring Graphics Quality 6-14
Balancing Visual Quality Against Network Performance 6-15
Enabling Configuration of Performance Options 6-16
Optimizing Performance
Configuring Trajectory Smoothing 6-17
Tuning the Target Frame Rate 6-17
DI-Guy Performance Settings 6-19
Optimizing Performance — Introduction
VR-Forces’s overall performance varies based on the following factors:
Size of the terrain database.
Amount of memory available on your computer.
Computer speed and processing power.
The number of objects (simulation objects and tactical graphics) in the scenario and how active the simulation objects are.
The number of objects you try to simulate on a given back-end.
The frequency of the tick rate.
The number of front-ends and back-ends you run on your computer.
VR-Forces supports the following methods for optimizing the performance of the simulation engine:
Adjusting the refresh rates. (For details, please see “Balancing Visual Quality Against Network Performance,” on page 6-15.)
Turning off processor-intensive features. (For details, please see “Miscellaneous Performance Configuration Options,” on page 6-12.)
Adjusting the network processing time.
Specifying the tick rate for a simulation object or component. (For details, please see “Setting the Tick Rate,” on page 6-13.)
Specifying a tick rate for the network interface. (For details, please see “Tuning the Network Interface,” on page 6-14.)
Specifying the VR-Forces sleep time. (For details, please see “Tuning the Target Frame Rate,” on page 6-17.)
Specifying the number of objects that you expect to simulate in the exercise.
Optimizing the terrain.
Using interest management. (For details, please see “Filtering Simulation Objects Using Interest Management,” on page 6-8.)
Optimizing Performance — Introduction
The performance of the front-end depends on:
Processor speed.
Video card. (Always use the latest drivers for your video card.)
Available memory.
Size of the terrain database.
The number and complexity of models loaded and how well they have been opti- mized for performance. For information about optimizing models, please see “Best Practices for Creating Models for VR-Forces,” on page 83-26.
Number of objects in the simulation and how active they are.
Use of model instancing.
You can display statistics to help you evaluate VR-Forces’s performance. For details, please see “Displaying Performance Statistics,” on page 6-6.
The following display features can affect performance:
Displaying performance statistics.
Use of ground clamping.
Displaying track histories.
Displaying height-above-terrain lines.
Displaying radio communications lines.
Enabling advanced lighting and various lighting effects.
Enabling dynamic ocean effects. When you are using Plan View observer mode, enabling wakes, spray effects, and the buoyancy model can seriously degrade performance. These features are disabled by default. If you inadvertently enable them and experience this problem, switching to Stealth mode and back to Plan View mode restores performance.
Anti-aliasing settings. For details, please see “Configuring Graphics Quality,” on page 6-14.
The following sections describe options for optimizing front-end performance:
“Clearing the Model Instancing Cache,” on page 2-52.
“Considerations and Limitations for Building Terrains,” on page 55-4.
“Filtering Simulation Objects Using Interest Management,” on page 6-8.
“Configuring the Ocean Height Map,” on page 55-17.
Optimizing Performance — Monitoring the Back-end Frame Rate
Figure 6-1. Frame Rate Monitor
To view the Frame Rate Monitor, choose View Frame Rate Monitor Panel.
Optimizing Performance — Displaying Performance Statistics
VR-Forces can display two kinds of performance statistics — OSG statistics (Figure
), and VR-Forces statistics (Figure 6-3). VR-Forces also has a function profiler that developers can use to assess the performance of new code.
Figure 6-2. OSG performance statistics
Performance Statistics Overlay
Function Profiler Overlay
Figure 6-3. VR-Forces performance statistics and function profiler
Optimizing Performance — Displaying Performance Statistics
Displaying performance statistics may affect performance. Displaying OSG statistics may affect performance more than VR-Forces statistics.
To display VR-Forces performance statistics:
Choose Settings Display. The Display Settings dialog box opens.
Select the Render Settings page (Figure 6-4).
Select the Show Performance Statistics Overlay check box. A statistics display is added to the window (Figure 6-3).
The VR-Forces Function Profiler is primarily for the use of developers who are debug- ging VR-Forces applications. For information about how to integrate the profiler into your code, please see Chapter 11, Using the Function Profiler in VR-Forces Developers Guide.
To run the VR-Forces Profiler:
Choose Settings Display. The Display Settings dialog box opens.
Select the Show Function Profiler Overlay check box. A statistics display is added to the window (Figure 6-3).
If you display OSG statistics and VR-Forces statistics at the same time, they overlay each other.
To display OSG performance statistics:
Press F2. The frame rate is displayed.
Continue pressing F2. Additional statistics are displayed. When all statistics are displayed, pressing F2 closes the display.
VR-Forces can use interest management to improve front-end performance in simula- tions that have high simulation object counts. Interest management is an implementa- tion of HLA data distribution management (DDM). When interest management is enabled, VR-Forces filters out all simulation objects that are more than a specified distance from the observer.
Optimizing Performance — Filtering Simulation Objects Using Interest Management
To use interest management:
You must use HLA (DIS does not support interest management).
If you are using the MÄK RTI, you must use MÄK RTI 3.4a or later.
You must configure your RTI to support DDM. (If you are using the MÄK RTI, you can configure your system to use ddm-rid.mtl, which has DDM enabled.)
To enable interest management, start vrfGui from the command line and include the --useGeographicDdm command line option with the HLA configuration commands, for example:
vrfGui -s 1 -a 3004 --hla -x MAK-RPR-2.0
--rprFomVersion 2.0 -F MAK-RPR2-1-1.fed
--useGeographicDdm
The region update threshold is a percentage of the distance from the center of the region to a side. When the observer moves beyond the threshold, the region is recalcu- lated. For example, if the region size is 1000 meters, the distance from the center to a side is 500 meters. If the region update threshold is 50%, when the observer moves more than 250 meters from the center of the region, VR-Forces recalculates the display region.
To configure interest management:
Choose Settings Display. The Display Settings dialog box opens.
Select the Interest Management Settings page (Figure 6-5).
In the DDM Region Size box, type a value for the region size.
In the Region Update Threshold box, type a value, as a percentage, for the update threshold.
Optionally, filter simulation objects based on the observer’s altitude, as follows:
Select the Hide Entities When Observer’s Altitude is Above check box.
Specify the observer altitude at which to hide simulation objects.
Click OK.
Optimizing Performance — Clearing the Model Instancing Cache
VR-Forces has a feature called model instancing that lets models share resources, such as geometry and textures. These shared resources are stored in a cache. Use of model instance caching decreases memory use and improves performance.
You can clear the model instancing cache if you need the disk space.
To clear the model instancing cache:
Choose Settings Application. The Application Settings dialog box opens.
Select the File Caching Settings page (Figure 6-6).
Click Clear Instancing Cache.
Optimizing Performance — Miscellaneous Performance Configuration Options
You can improve front-end performance by limiting use of display features, as follows:
Turn off track histories.
Limit use of object transparency.
Limit use of spot reports.
In DIS, use asynchronous I/O.
For streamed data, use incremental compiling.
Use of spot reports can degrade performance. You may want to limit the number of simulation objects for which they are generated or disable spot reports entirely. You can also specify that spot reports be sent only to the front-end. For details about using spot reports, please see “Displaying Simulation Objects Based on Spot Reports,” on
page 9-2.
By its nature, DIS generates a lot of network traffic. Therefore, you may experience problems with dropped packets and simulation objects may time out. You can mitigate this problem by using asynchronous I/O. To use asynchronous I/O, start with the
--useAsyncIO command line option or select Use Asynchronous I/O in the Simula- tion Connections Configuration dialog box.
Users of streamed terrains might want to consider using incremental compiling. This is an OSG option that allows the processing of streamed data to be spread across multiple frames, reducing performance spikes. To use it, create the environment variable OSG_ICO. (It does not need a value. It just needs to exist.)
Using OSG_ICO may cause LOD issues with other paged formats. It is only recommended for streamed terrains.
Optimizing Performance — Setting the Tick Rate
VR-Forces lets you tune performance by varying the tick rate of components, state repositories, and network interfaces. By decreasing the frequency with which some simulation object components are ticked, you make more CPU time available to other simulation objects. For example you could decrease the tick rate for slow moving enti- ties such as dismounted infantry entity or a command post, making more CPU avail- able for entities such as aircraft or missiles.
Variable tick rates are determined by a minimum tick period and a minimum tick period variance. The minimum tick period parameter specifies the shortest period of time, in seconds, that can elapse between ticks of a simulation object’s components. VR-Forces may tick the components less frequently (due to heavy CPU load), but it will never tick the entity’s components more frequently than specified.
To reduce the frequency that a component can be ticked, increase the minimum tick period value. To increase the frequency that a component can be ticked, reduce the minimum tick period value.
The minimum tick period variance argument specifies an amount of variance allowed around the minimum tick period. Specifying a minimum tick period variance value helps prevent the spikes in CPU usage that would result if all components tried to tick at the same time. Calculation of the time to tick a component using minimum tick period variance is as follows (the example uses the entity component arguments):
If the current time is t0 and the next scheduled tick is tnext then:
tnext = t0 + min-tick-period +/- rand(min-tick-period-vari- ance/2)
If you insert some sample values (in seconds), you get:
tnext = .1 + .05 +/- rand(.05/2)
This means that the next tick will be no sooner than the current time plus .15 seconds plus or minus a random value between 0 and .0125 seconds.
If the next tick time calculated by this formula is less than the current tick time, it is set to the current tick time, which results in the component being ticked on the next tick.
In the object parameter database, you can specify a min-tick-period and min-tick-period-vari- ance for each simulation object and for individual simulation object components. The component-level settings, if any, override the simulation object-level settings. You can update these parameters in the OPD Editor.
Optimizing Performance — Configuring Graphics Quality
You can tune the local and remote network interface subcomponents. Specify the net- interface-min-tick-period and net-interface-min-tick-period-variance parameters in the local and remote subcomponents blocks. If you reduce the rate at which the network interfaces are ticked, you can limit how often VR-Forces needs to do coordinate system conver- sion from network (geocentric) to database coordinates.
Reducing the frequency with which you tick network interface components could delay the discovery of objects in remote front-ends and back-ends.
You can tune the frequency with which state repositories get ticked. Specify the state- repository-min-tick-period and state-repository-min-tick-period-variance parameters in the local and remote subcomponents blocks. These parameters control how often VR-Forces recomputes the bounding volume of an object based on object geometry.
--antiAliasing level. Anti-aliasing is a technique used to reduce the jagged edges of digital graphics. You can set the level to 0, 2, 4, 8, or 16. Default: 4.
--depthBits depth. The number of bits in an image determines its quality and the number of colors it supports. You can set the depth to 24 or 32. Default: 24.
--stencilBits bits. The stencil buffer can be set to 0 or 8. Default: 8.
--alphaBits bits. Specifies the number of alpha bits – 0 or 8.
On older graphics cards, you may need to set anti-aliasing to 0 to improve performance.
Depending on your graphics card and driver, some combinations of these settings may be incompatible. For example, if you set stencil bits to 8, the depth must be set to 24 and anti-aliasing may need to be set to 0 or 2.
Optimizing Performance — Balancing Visual Quality Against Network Performance
./appData/settings/vrfSim/vrfSimSettings.xml. Changes to the default thresholds get saved
in vrfSimSettings.xml.
Changes made at runtime have no effect in the following cases:
If a back-end joins the scenario after the thresholds are sent. It uses the default VR- Link thresholds, or the values in the vrfSimSettings.xml file, if specified.
If an object was instantiated with a customized VR-Link DtThresholder.
To configure performance options:
Choose Settings Application. The Application Settings dialog box opens.
Select the Performance Options page (Figure 6-7).
Adjust the Visual Quality slider to your desired preference for visual quality versus network performance.
To have VR-Forces calculate the smoothing period, select Override Smoothing Period. To specify the smoothing period yourself, select Use Specified Smoothing Value and use the slider to set the smoothing period you want to use.
Optimizing Performance — Trajectory Smoothing
The dr-allow-gui-overrides configuration parameter, specified in each OPE file, determines whether a given entity type can have its translation and rotation thresholds overridden by the value set by the Performance Options page.
From the time VR-Forces receives a state update message for a simulation object until it receives the next update, it calculates the location of the simulation object based on the heading and acceleration in the most recent state update. This process is called dead- reckoning. When the next state update arrives for the simulation object, VR-Forces moves it to the new position. If the actual position is significantly different from the dead-reckoned position, the simulation object could appear to jump from the dead- reckoned position to the actual position. VR-Forces can eliminate these discontinuities by smoothing trajectories and rotation paths.
Figure 6-8 illustrates dead-reckoning and smoothing.
Dead- | ||
reckoned | ||
position | ||
Updated position | Updated position | |
Dead- | ||
reckoned | ||
position | ||
Last update |
Frames 1-5 Frame 6+ Frame 6+ without smoothing with smoothing
Figure 6-8. Dead-reckoning and smoothing
The smooth period is the period of time over which smoothing takes place. The default period is 1/10 second. If course corrections appear abrupt with this setting, you may want to increase the smooth period.
Smoothing makes fast-moving entities, such as fixed wing aircraft, look better. Slow moving entities, such as dismounted infantry, may look worse. If your simulation is mostly one or the other of these types of entities, enable or disable smoothing as appropriate for the best visualization experience.
Optimizing Performance — Tuning the Target Frame Rate
To configure trajectory smoothing:
Choose Settings Application. The Application Settings dialog box opens.
Select the Use Specified Smoothing Value option. The Enable Smoothing check box becomes enabled.
To enable or disable smoothing, select or clear the Enable Smoothing check box.
To change the smooth period, adjust the Smoothing Period slider or type a value, in seconds, in the box.
The --targetFrameRate command line option and vrfSim.mtl parameter allow you to specify the mean frame rate above which the VR-Forces back-end should begin to sleep in order to give up CPU time to other processes. This parameter is only applicable to variable frame mode; the fixed frame modes already have a built in sleep that gives up unused time. Increasing the target frame rate will only prevent the back-end from sleeping if it cannot achieve that rate – ultimately it is up to the operating system to determine how much CPU time each process receives.
Optimizing Performance — Coloring Draw Calls
One of the factors that affects performance is the number of draw calls it takes to render a scene. VR-Forces lets you color the draw calls in a scene so that you can see which objects may be creating performance problems.
When you color draw calls, all the drawables in the scene are randomly colorized. The colors themselves do not convey any meaning. The important information is the number of draw calls required for a model. For example, if a vehicle has 25 different colored parts, you know that it requires 25 draw calls and you may want to edit the model to use fewer of them.
Figure 6-9 illustrates a tank with its drawables colorized.
Figure 6-9. Colorized drawables on tank
The colors do not update as new information comes into the scene. Therefore, you can refresh the colorization.
To visualize draw calls:
Choose Settings Display. The Display Settings dialog box opens.
Select the Colorize Per Drawable check box.
To refresh the display, click Refresh.
Optimizing Performance — DI-Guy Performance Settings
In some cases, if the frame rate cannot quite keep up with the refresh rate, VSync can force the frame rate to a noticeably lower rate. To avoid this problem, we recommend that you enable triple buffering for your video card. You must do this in the video card’s configuration application; VR-Forces cannot do this for you.
By default, VSync is disabled. If you want to ensable it, startup with the
--enableVSync command-line option, or you can configure your video card to force it to be on.
The following settings affect performance of DI-Guy human characters:
Maximum draw distance. VR-Forces will not render characters that are farther away from the observer than this distance.
Enable instancing. Enabling instancing improves performance by reusing model data for similar characters. You can set the LOD beyond which instancing is used. You can visualize instanced characters.
Optimizing Performance — DI-Guy Performance Settings
To specify DI-Guy performance settings:
Choose Settings Display. The Display Settings dialog box opens.
Select the DI-Guy Settings page (Figure 6-10).
To set the maximum draw distance, adjust the Max Draw Distance slider or change the value in the box.
Optionally, select or clear the Use Multi-threaded Update check box.
Optionally, select or clear the Enable Instancing check box.
If instancing is enabled, adjust the Instancing LOD slider or change the value in the box.
Optionally, select or clear the Visualize Instancing check box.
Whenever you use VR-Forces, you work in the context of a scenario. A scenario consists of everything that needs to be specified to run a VR-Forces simulation. Each scenario has a scenario file (.scn) and the following supporting files:
An order of battle file (.oob).
A plan file (.pln).
An object map file (.omp).
A terrain database for the front-end and back-end.
An overlay file (.ovl).
A scripts file (.spt). This file contains the scenario scripts, if any.
A selection groups file (.sgr).
A scenario “extras” file (.xtr). This file records hostility relationships and stores spawn pattern templates.
A saved views file (.osrx). If a scenario has captured observer views, they get saved automatically. You can also specify a startup view.
A settings file that records scenario-specific GUI settings (.gui_settings).
By default, scenarios are saved in a compressed zip archive with the extension .scnx. If you examine a compressed scenario file in an unzipping application, you will see that it contains the individual files described in the previous paragraphs.
For details about scenario files, please see Chapter 12, Scenario Files.
VR-Forces Users Guide
Section II - Scenarios
II-1
Scenarios
Section II - Scenarios
II-2 VT MAK
7. Creating and Running Scenarios
This chapter explains how to create, load, run, and save scenarios.
Specifying Multiple Simulation Model Sets 7-8
Creating Simulation Model Set Configurations 7-9
Setting the Scenario Starting Date and Time 7-11
Importing (Merging) Scenarios 7-12
Importing and Exporting MSDL 7-14
Loading a Recently Loaded Scenario 7-18
Loading a Scenario from the Command Line 7-18
Load Balancing a Scenario 7-19
Displaying Scenario Information 7-21
Editing the Scenario Description 7-23
Changing the Simulation Speed 7-24
Saving a Previously Saved Scenario 7-29
Saving a Scenario to a New Name or a Different Format 7-29
Checkpoints and Snapshots 7-30
Creating and Running Scenarios
Clearing the Snapshot List 7-34
Pausing a Scenario Automatically 7-35
Setting the Scenario End Time for a New Scenario 7-35
Setting the Scenario End Time for an Open Scenario 7-35
Running VR-Forces in Batch Mode 7-36
Running VR-Forces in Batch Mode 7-39
Recording Batch Scenarios 7-40
Sending Run and Pause Messages to Simulation Participants 7-41
Recording VR-Forces Simulations with the MAK Data Logger 7-41
To use VR-Forces to simulate simulation objects, you must load a scenario or create a new one. When you start VR-Forces, the Scenario Startup screen asks you if you want to create or load a scenario (unless you have disabled this feature). Thereafter, to create a scenario, use the procedure in this section. (For details about creating a scenario from the Scenario Startup screen, please see “Starting VR-Forces from the VR-Forces Launcher,” on page 4-3.)
If you are using multiple front-ends in the same session, when one of them creates a scenario, the terrains in all other front-ends are closed (unless the terrain is the same as that for the new scenario) and the terrain for the new scenario is loaded.
To create a scenario:
Choose File New Scenario, or click the New Scenario button ( ) on the File Toolbar. The Initial Scenario Information dialog box opens (Figure 7-1). By default, it opens in ./userData/terrains, the directory that contains the terrain files shipped with VR-Forces. (For a brief description of the databases supplied with VR-Forces, please see “Terrain Databases Provided with VR-Forces,” on
page 53-19. For details about terrain files, please see Section X, “Terrain”.)
If you choose an MTF file and an MTD file with the same name exists, the back-end loads the MTD file. (MTD is a legacy format that may be present for older terrains.)
Click Open. The New Scenario dialog box opens (Figure 7-2).
Select the SMS for the type of scenario you want to run – entity-level or aggregate- level.
Optionally, set other basic scenario parameters. Table 7-1 describes the basic parameters.
Table 7-1: Basic scenario parameters
Parameter Description
Parameter Description
Scenario Name Specifies the name of the scenario. This is the name used to iden- tify the scenario when you join a session. If you do not specify a name, the scenario file name is used.
Simulation Terrain
Simulation Model Set
Scenario Description
Attach Compo- nents to Remote Entities On
Specifies the terrain to be used by the back-end. By default, this is the terrain you selected in the Initial Scenario Information dialog box. However, you can change it if you want to.
The simulation model set to use. For entity-level scenarios, choose EntityLevel.sms or an SMS similar to it; for aggregate-level scenarios, choose AggregateLevel.sms or a similar SMS.
The scenario description lets you provide a description of the scenario. This may be useful to remind you or other VR-Forces users of its purpose or special details. You can enter the descrip- tion as plain text or as HTML. If you use HTML, when the descrip- tion is displayed in the Scenario Information dialog box, it is displayed using the HTML formatting.
Specifies whether or not to attach components to remote entities, and if so, the back-ends on which to manage the components that are being attached to remote entities. Unlike other scenario parameters, you can change this value when you load a scenario. For details about configuring components for attachment to remote entities, please see “Attaching VR-Forces Components to Remote Entities,” on page 76-2.
!
!
This value is not saved in the scenario file. To attach components in future runs of the scenario, you must specify the appropriate setting each time you load the scenario.
For more information about these parameters, please see “Scenario Parameters,” on page 12-4.
Optionally, select the Advanced tab (Figure 7-3) and set advanced scenario parame- ters (overriding the default settings).
Figure 7-3. New Scenario dialog box, Advanced tab
Table 7-2 describes the parameters you can set.
Table 7-2: Advanced scenario parameters
Parameter Description
Parameter Description
Use the Simula- tion Terrain in the Display
Use a Different Terrain for the Display
Simulation Model Sets
Component Attachment Table
If selected (the default), the scenario uses the same terrain for the front-end and back-end.
If selected, lets you specify the terrain to be used by the front- end.
Lets you specify simulation model sets other than or in addition to the default SMSs listed on the Basic tab. A scenario must specify at least one simulation model set. For more information, please see “Specifying Multiple Simulation Model Sets,” on page 7-8.
Default: EntityLevel.sms.
If you plan to attach components to remote entities, specify the component attachment table that you want to use. For details about configuring components for attachment to remote entities, please see “Attaching VR-Forces Components to Remote Enti- ties,” on page 76-2.
Table 7-2: Advanced scenario parameters
Parameter Description
Parameter Description
Create Global Dynamic Terrain Processor
Create Global Environment
Starting Date and Time
Scenario End Time
Use Day/Night Illumination Model
Random Number Seed
If selected the global dynamic terrain processor monitors the entire terrain for dynamic terrain changes. If disabled, dynamic terrain is not supported unless you create a dynamic terrain area.
Specify the date and time of day at which the simulation should start. As time advances, the Environment Settings Toolbar daylight icon changes coloration. In 3D, the sky coloration also changes as time advances. This is a back-end setting. Default: current date at 10:00 A.M.
The simulation time at which to automatically pause the scenario. For more information, please see “Setting the Scenario End Time for a New Scenario,” on page 7-35.
If selected, use an ephemeris model in the back-end to calculate illumination. This affects sensors. If cleared, the entire world is fully illuminated regardless of the time of day. For more informa- tion, please see “Choosing the Illumination Model,” on page 11-4.
Specify a random number seed as an integer >= 0.
Frame Mode Select a frame mode from the list.
Frame Time Specifies the length of a frame, in seconds. This parameter is not enabled if Frame Mode is variable-frame.
For more information about these parameters, please see:
Click OK. The scenario information is displayed and the terrain is displayed in the Plan View (2D) observer mode.
Add the simulation objects and tactical graphics that you need for your simulation. For information about adding simulation objects and tactical graphics, please see Chapter 16, Creating and Placing Objects.
Save the scenario. For details about saving scenarios, please see “Saving a Scenario,” on page 7-27.
You can specify more than one simulation model set for a scenario. One strategy for extending VR-Forces is to use an SMS provided with VR-Forces for the majority of objects and to create a separate SMS for customized simulation objects. As you upgrade to newer versions of VR-Forces, you can more easily migrate your customized SMS to the new version because your changes have not been integrated into the default SMS. (You can also include the SMSs provided by VR-Forces in your custom SMS. In that case you would just load the custom SMS and not multiple SMSs. For more informa- tion, please see “Simulation Model Sets,” on page 64-5.)
If you routinely use more than one SMS, consider creating an SMS configuration. For details, please see “Creating Simulation Model Set Configurations,” on page 7-9.
When you load multiple SMSs, if there is any overlap in the objects they specify, the last SMS loaded overrides previous SMSs.
!
!
Do not use an entity-level SMS and an aggregate-level SMS together. The simulation objects from the two SMSs will not be able to interact.
To specify multiple simulation model sets for a scenario:
In the New Scenario dialog box, click the Browse button on the Simulation Model Set line. The Simulation Model Set Files dialog box opens. It lists the SMS files to be loaded for this scenario.
Figure 7-4. Simulation Model Set Files dialog box
In the Simulation Model Set Files dialog box, click Add Model Set. A blank line is added to the window (Figure 7-5).
Click the Browse button next to the blank line. The Choose File dialog box opens.
Select a simulation model set and click Open. The SMS is added to the text box.
Click OK.
Complete the New Scenario dialog box.
When you create a new scenario, you specify an SMS in the Initial Scenario Informa- tion dialog box (see “Creating a Scenario,” on page 7-3 for details). The Simulation Model Set list lists all SMSs in ./data/simulationModelSets. The SMSs are listed in alpha- betical order. If you want a particular SMS to be the default SMS you can create an SMS configuration and specify that it be the default. You can create as many SMS configurations as you want. An SMS configuration can have more than one SMS in it. So if you routinely create scenarios that use multiple SMSs, creating a configuration can save you from the necessity of always specifying the additional SMSs on the Advanced tab of the New Scenario dialog box (as described in “Specifying Multiple Simulation Model Sets,” on page 7-8).
The Simulation Model Set list in the New Scenario dialog box lists all SMS configurations and all SMSs. It does not duplicate names, so if an SMS configuration has the same name as an SMS, only the SMS configuration is listed.
To create a simulation model set configuration:
Choose Settings Application. The Application Settings dialog box opens.
Select the Session Options page (Figure 7-6).
Figure 7-6. Session Options page
Click the Add button ( ) on the Simulation Model Set Configuration line. The Configuration dialog box opens.
Type a name for the configuration.
Click OK. The new configuration is added to the list.
Click Add Model Set. A line is added to the window.
Click the Browse button at the end of the new line. A file chooser dialog box opens.
Select the SMS you want to put in this configuration.
Click Open. The SMS is added to the list.
Optionally, add additional SMSs to this configuration.
Click Close.
Specifying an SMS as the default SMS automatically removes that designation from any other SMS.
To specify the default SMS configuration:
Choose Settings Application. The Application Settings dialog box opens.
In the Simulation Model Set Configuration list, select the configuration that you want to be the default.
Click the Star button ( ). A star is displayed next to the configuration name in the list, indicating that it is the default configuration.
By default, when you create a scenario, the starting simulation date and time is the current system date at 10:00 A.M. local time, where the local time zone is determined by the longitude of the first entity that gets created in the scenario.
You can change the starting date and time when you create a scenario and you can change the default time used for new scenarios. When you set the scenario time when you create a scenario, or the default scenario start time used for new scenarios, that time is in the time zone that is currently set in the environment settings.
For more information about simulation time, please see “Setting the Date and Time of Day,” on page 11-2.
To set the scenario start date and time:
Begin the scenario creation process, as described in “Creating a Scenario,” on page 7-3.
When the New Scenario dialog box opens, select the Advanced tab (Figure 7-3).
In the Starting Date and Time box, specify the starting date and time.
Continue creating the scenario.
You can change the default starting date and time for scenarios.
To set the default starting date and time:
Choose Settings Application. The Application Settings dialog box opens.
Select the Start Simulation at Specified Date/Time option.
Specify the starting date and time.
VR-Forces users often assign scenario development to multiple persons or teams. Then they merge the separately-developed scenarios into a master scenario. You can easily merge scenarios by importing them. When you import a scenario, you can choose to rename simulation objects to avoid duplicate names, to import scenario events, and to create a selection group for the imported simulation objects.
!
!
If you import a scenario that was saved (checkpointed) with a simulation time that is different from the current time of the scenario into which you are importing it, there may be unexpected behaviors due to timing issues. For example, an entity executing a Wait Duration task may wait for a longer or shorter time than you expect.
To import a scenario:
Open a scenario.
Choose File Import VR-Forces Scenario. The Import Scenario dialog box opens (Figure 7-7).
Select the scenario that you want to import.
Optionally, on the Deconflicting Name box, specify a text string that VR-Forces should add to object names in the imported scenario that match names in the base scenario.
Optionally, to allow duplicate names, clear the Generate New Unique Names on Import check box.
Optionally, specify whether or not to import scenario events.
Optionally, specify whether or not to create a selection group.
VR-Forces does not import all of the information that can be in an MSDL file. It imports and exports:
Simulation objects and their locations. Locations are always exported in geocentric coordinates.
Force relationships and hostility relationships.
Unit formations.
Tactical graphics.
To import MSDL:
Create or load a scenario.
Choose File Import Scenario Laydown. The Import Scenario File dialog box opens.
Select the MSDL file that you want to import.
Click Open.
To export a scenario to MSDL:
Create or load a scenario.
Choose File Export Scenario Laydown. The Export Scenario dialog box opens.
Type a name for the file.
Click Save. If VR-Forces is not sure how to export an entity type to MSDL, the Export MSDL Scenario dialog box opens (Figure 7-8).
For each object type listed in the Export MSDL Scenario dialog box:
In the Symbol Identification column, click the value. A list of possible identifi- cation codes is displayed. (These codes are from the MSDL specification. You will need to familiarize yourself with the specification to fully understand them.)
Select the proper identification.
Click OK.
Create simulation object groups. Simulation objects groups are heterogeneous groups of simulation objects and tactical graphics that you can add to any scenario. Like the individual simulation objects that you can add to a scenario, they are not tied to a terrain location until you add them. Use them if you want to create a repeatable set of objects that do not fit into a unit hierarchy. For more information, please see “Simulation Object Groups,” on page 16-25.
Use scenario import. If you have a base scenario that you want to use repeatedly, create the scenario, then open it and rename it to preserve the original, or open a new scenario and import the base scenario. You can do this with a fully realized scenario or a scenario layout that you want to add to other scenarios. For example, you might want to create a town with background traffic for repeated use with different training problems added to it. Since this is a scenario, it is tied to the terrain location you use when you create it. Alternatively, you might have a set of scripts that you do not want to promote to system scripts. You can save them in a scenario and import the scenario into the scenarios for which you want to use the tasks. For more information, please see “Importing (Merging) Scenarios,” on
page 7-12.
Import MSDL. If you have a MSDL entity laydown, you can import that into different scenarios as needed. For more information, please see “Importing and Exporting MSDL,” on page 7-14.
After you have created and saved a scenario, you can load it and run it on any platform supported by the version of VR-Forces in which you created it. Most scenarios are forward compatible. Please see VR-Forces Release Notes for compatibility issues.
If you are running multiple front-ends in the same session, when you load a scenario, any terrains that are open on other front-ends are closed and the terrain for the newly loaded scenario is opened.
When you load a scenario that uses multiple back-ends, if any of the required back-ends are not running, VR-Forces prompts you to remap the objects in the scenario. The Remap Missing Back-ends dialog box lists the unavailable back-ends and the available back-ends. You can specify which back-ends to map objects to or you can select “map all to” and map all objects to one back-end. For more information about remapping back-ends, please see “Remapping Back-ends,” on page 3-8.
To load a scenario:
Choose File Load Scenario or click the Open Scenario button ( ) on the File Toolbar. The Load Scenario dialog box opens (Figure 7-9).
Select a scenario to load. Basic information about the scenario is displayed (Figure 7-10). Scenarios are files with the suffix .scn or .scnx. Sample scenarios are located in the ./userData/scenarios directory. (Batch scenarios, described in “Running VR- Forces in Batch Mode,” on page 7-36, have the suffix .bsn.)
Optionally, specify whether or not to allow management of components on remote entities by selecting an option in the Attach Components to Remote Entities On list. For details about configuring components on remote entities, please see “Attaching VR-Forces Components to Remote Entities,” on page 76-2.
Optionally, select a load balancing option.
Click Open.
VR-Forces keeps a list of the scenarios you open. You can quickly open a scenario from the list.
To open a recently used scenario, choose File Recent Scenarios scenario_name.
If you start VR-Forces from the command line, you can specify a scenario to load. You can specify the scenario in the back-end or front-end. The other executable will load it as soon as it starts up.
To load a scenario when you start the back-end, use the -L command-line option, for example:
vrfSimDIS -s 1 -a 3001 -L “../userData/scenarios/mySce- nario.scnx”
To load a scenario when you start the front-end, use the --scenarioFile
command-line option, for example:
vrfGui --scenarioFile “../userData/scenarios/mySce- nario.scnx” --dis -s 1 -a 3000
After you create a scenario, you may decide that you want to spread simulation of objects across more back-ends than you used to create it. You would typically increase the number of back-ends to improve performance. The process of spreading the simula- tion work across multiple simulation engines is called load balancing. VR-Forces supports even distribution (done automatically by VR-Forces) and manual load balancing.
!
!
If you are using interest management to support large simulation object counts, do not enable load balancing. It will negate the assignment of simulation objects to specific back-ends that is part of designing a scenario for interest management.
To load-balance a scenario:
Choose File Load Scenario. The Load Scenario dialog box opens.
In the Load Scenario dialog box, select an option from the Load Balancing list (Figure 7-11).
Figure 7-11. Load Balancing list
In the Object Mapping dialog box, expand the list for the back-end from which you want to distribute objects.
Redistribute objects by dragging them from a source back-end to a target back-end, or by cutting them from the source back-end and pasting them onto the target back-end. You can view the new distribution of objects by expanding the list for the target back-end.
Click OK. The scenario loads. If you open the Information dialog box for an object, the title bar displays the back-end on which it is simulated.
To preserve the new object mappings, save the scenario. When you save the scenario, you are prompted to save the original mappings. Click No to save the new load balanced mappings.
When you create a scenario, you specify a variety of parameters (or accept default values) and, optionally, specify a name and description for the scenario. If a scenario has a description, when you load the scenario, the Scenario Information dialog box opens automatically. (You can disable this behavior.)
You can display scenario information at any time while a scenario is loaded. You can edit the scenario description. Other values are read only. (You can edit them directly in the scenario file. For details, please see “The Scenario File,” on page 12-3.)
To display scenario information:
Choose File Scenario Information. The Scenario Information dialog box opens (Figure 7-13).
To view advanced parameters, select the Advanced tab.
To disable display of scenario information when a scenario is loaded, use one of the following methods:
When the Scenario Information window opens, select the Never Show Again check box.
To enable the Scenario Information dialog box, on the Application Settings dialog box, Session Options page, select the Show Scenario Information Dialog check box.
You can edit a scenario’s description in the Scenario Information dialog box.
To edit a scenario’s description:
Choose File Scenario Information. The Scenario Information dialog box opens (Figure 7-14).
Click Edit. The description window changes to edit mode and the button text changes to View.
Edit the text.
To see how the text will be displayed, click View.
Click OK.
VR-Forces includes several sample scenarios. Chapter 14, Example Entity-Level Scenarios has the step-by-step process for creating the breaching scenario and the embarkexample scenario. VR-Forces First Experience Guide has two simple tutorials for scenario creation.
When you load a scenario, it opens in the paused state unless you start with the -L and
-r back-end command line options.
To run a scenario, choose Simulation Run Scenario, or click the Run button ( ) on the Simulation Control Toolbar (Figure 7-15).
Rewind Roll back Run Pause
Figure 7-15. Simulation Control Toolbar
!
!
To change the speed of a simulation, drag the indicator on the Simulation Time Scale Toolbar (Figure 7-16), or type a value in the text box.
Figure 7-16. Simulation Time Scale Toolbar
Creating and Running Scenarios — Running a Scenario
By default, the range for the Simulation Time Scale Toolbar is 1 to 15. You can change the range. To change the range, edit the following lines in
./appData/settings/vrfGui/default_SessionSettings.srsx:
<myTimescaleLow>1</myTimescaleLow>
<myTimescaleHigh>15</myTimescaleHigh>
To pause a simulation, choose Simulation Pause Scenario, or click the Pause button ( ) on the Simulation Control Toolbar (Figure 7-15).
An initial snapshot is taken of a scenario when you play it even if periodic snapshots is not enabled. The initial snapshot is used for rewinding.
To rewind a scenario, choose Simulation Rewind to Scenario Start, or click the Rewind Scenario to the Beginning button ( ) on the Simulation Control Toolbar (Figure 7-15).
If you do not pause a scenario before you rewind it, it starts playing again immediately.
You can roll back to any of the available snapshots or checkpoints. When you roll back to a snapshot, VR-Forces loads the scenario as it existed at the point of that snapshot. When you run the snapshot, all snapshots from a later time than the one you rolled back to are deleted. Older snapshots are kept in memory. New snapshots are taken starting from the loaded snapshot.
Once snapshots are deleted based on the maximum number of snapshots being reached, you cannot roll back to them. If you have saved periodic checkpoints, you can load them using the Load Scenario command on the File menu.
To roll back to a snapshot or checkpoint:
Choose File Scenario Snapshots, or on the Checkpoint Settings page, click Show Snapshots. The Scenario Snapshots dialog box opens (Figure 7-17).
Select the snapshot or checkpoint you want to roll back to.
Click Roll Back.
To close a scenario, choose File Close Scenario, or click the Close Scenario button ( ) on the File Toolbar.
The first time you save a scenario, VR-Forces saves the path of the terrain database and other scenario configuration data to a scenario file (extension .scn). (Paths are saved rela- tive to the ./bin64 directory.) This information usually does not change between runs of a scenario. Every time you save a scenario, VR-Forces saves the order of battle, the plans, and object mapping information to individual files that have the same name as the scenario, but with file extensions that identify the information in the file (.oob, .pln,
.xtr, .omp, and so on). By default, all these files are saved to a compressed archive with the extension .scnx. However, you can save them as individual files, as explained in this procedure.
!
!
If you want to keep the initial state of a scenario (simulation time = 0 and no simulation has taken place), so that you can repeatedly run a simula- tion from the beginning, save the scenario when you have finished creating it, but before you run it. Then, do not save the scenario again under the same name (unless you specifically want to change the original state of the scenario). (If you forget to save a new scenario, you can rewind to the initial snapshot and save it.)
If you load an alternate terrain in a front-end when it joins a session, the alternate terrain is not saved as part of the scenario.
When you run a saved simulation, all simulation objects resume whatever they were doing when the scenario was saved.
If simulation objects are executing scripted tasks, some information regarding the tasks is not saved. For details, please see “Limitations for Checkpointing Scripts,” on page 33-12.
Creating and Running Scenarios — Saving a Scenario
Save behavior depends on when you save a scenario, as follows:
If you save a previously saved scenario after it has started (whether it is paused or running), it is not saved to the original scenario file. It is saved to a checkpoint that is named using the convention scenario_name_at_time_time.scn. This ensures that you cannot inadvertently overwrite the original scenario file. To overwrite the orig- inal scenario, you must use Save Scenario As. For more information, please see “Saving Checkpoints,” on page 7-30 and “Saving a Previously Saved Scenario,” on page 7-29.
If you run a new scenario without saving it and save it at some simulation time greater than zero, it is saved using whatever name you provide. The time is not included in the scenario name.
To save a new scenario:
Choose File Save Scenario or click the Save button ( ) on the File Toolbar. The Save Scenario dialog box opens.
Select the directory in which you want to save the scenario.
If you create a folder in the Save dialog box and it has a space at the end of the name, Windows does not recognize the existence of the folder. If you try to delete it, the system may blue screen. Running scandisk can solve this problem.
Give the scenario a name.
By default, scenarios are saved in a compressed archive (*.scnx). If you want to save a scenario as individual files, in the File of Type list, select MAK Scenario Format (*.scn).
Click Save. All scenario files are saved with the new name.
If you save a remapped scenario, you are prompted to save the scenario with the original mappings or with the remappings.
In most computer applications, when you save a file that has been saved previously, the current version of the file simply overwrites the previously saved version. However, when VR-Forces saves a scenario, the save action depends on the status of the scenario. VR-Forces tracks the simulation time of the scenario. When you save a scenario:
If a version of the scenario exists with the current simulation time, VR-Forces displays a message indicating that a version of the scenario at that simulation time exists and asks if you want to overwrite it.
If there is no version with the current simulation time, VR-Forces creates a new checkpoint at the current simulation time, using the checkpoint naming conven- tion.
This behavior ensures that if you change a scenario after you have started a simulation, you will never inadvertently overwrite the original version or another checkpoint.
To save a previously saved scenario, choose File Save Scenario.
You can save a scenario to a different name. You can also save it to a different format. That is, you can saved a scenario that was originally saved as a compressed archive to individual files or save individual files to a compressed archive.
If you save a scenario to a different format and you use the same name, VR- Forces does not replace the previously saved files with the new format. The two sets of files live side-by-side. Therefore we recommend that you give the newly saved scenario a different name or remove the old files to avoid confusion between different versions of the same scenario.
To save a scenario to a new name:
Choose File Save Scenario As. The Save Scenario dialog box opens.
Select the directory in which you want to save the scenario.
Give the scenario a name.
If you are changing the format, select an option in the Files of Type list.
Click Save. The scenario is saved to the new name.
As noted in “Saving a Scenario,” on page 7-27, each time you save a scenario, you are essentially creating a checkpoint. A checkpoint saves the state of a scenario to disk and allows you to run the scenario starting from the point at which it was saved. Since a checkpoint is saved to disk, you can return to it at any time. However, the time spent saving to disk may briefly interrupt scenario progress.
When you load a scenario, any snapshots in memory get discarded.
You can configure the frequency with which snapshots are saved and how many to keep in memory at a time. You can save snapshots as checkpoints.
You can save checkpoints in the following ways:
Save the scenario.
Save a snapshot as a checkpoint.
Enable periodic checkpointing.
Checkpoints are saved to the same directory as the base scenario unless you specify otherwise. If periodic checkpoints are enabled, the Status bar displays the time until the next checkpoint.
If simulation objects are executing scripted tasks, some information regarding the tasks is not saved. For details, please see “Limitations for Checkpointing Scripts,” on page 33-12.
When you run a checkpoint, simulation objects resume the tasks that they were executing at the time the checkpoint was saved. If detonations were scheduled or if missiles were in flight, they resume their former state.
Whenever you save a scenario, it creates a checkpoint.
To save an individual checkpoint, choose File Save Scenario.
If you enable periodic snapshots, you can save the snapshots as checkpoints.
To save a snapshot as a checkpoint:
Choose File Scenario Snapshots. The Scenario Snapshots dialog box opens (Figure 7-19). It lists all of the snapshots available.
Select the snapshots that you want to save as checkpoints.
Click Save Checkpoint. The snapshots are saved to checkpoints.
You can configure VR-Forces to save checkpoints at regular intervals. When VR-Forces saves a checkpoint, it is actually saving the snapshot taken at the checkpointing interval. Therefore, to schedule periodic checkpoints, you must enable periodic snapshots.
To schedule checkpoints:
Choose Settings Application. The Application Settings dialog box opens.
Select the Checkpoint Settings page (Figure 7-20).
Select the Enable Periodic Snapshots check box.
In the Snapshot Period box, specify how frequently VR-Forces should take snap- shots.
Select the Enable Periodic Checkpointing check box.
In the Checkpoint Frequency box, specify how frequently to save checkpoints as a function of the number of snapshots taken. For example, 4 means save every fourth snapshot as a checkpoint. If you save snapshots every 30 seconds, then you would save a checkpoint every two minutes.
Optionally, specify the directory in which to save the checkpoints. If you leave this box blank, they are saved to the directory where the base scenario is located.
To disable periodic checkpointing:
Choose Settings Application. The Application Settings dialog box opens.
Clear the Enable Periodic Checkpointing check box.
You can delete checkpoints manually in a file browser, like you can delete any other files on your computer. You can also easily delete them from the front-end.
To delete checkpoints:
Choose File Delete Scenario Checkpoints. The Delete Checkpoints dialog box opens (Figure 7-21).
Select the checkpoints that you want to delete.
Click Delete Selected.
You can create snapshots manually and you can specify that they be created automati- cally at a specified interval.
To create a snapshot:
Choose File Scenario Snapshots, or on the Checkpoint Settings page, click Show Snapshots. The Scenario Snapshots dialog box opens (Figure 7-19).
Click Snapshot.
You can also create a snapshot by clicking the Snapshot button 
) on the Scenario Toolbar.
When you enable periodic snapshots, you specify how frequently to take them, in simu- lation time, and the maximum number to store in memory at a time. If the number of snapshots reaches the maximum, VR-Forces drops the oldest snapshot and adds the newest.
To enable periodic snapshots:
Choose Settings Application. The Application Settings dialog box opens.
Select the Enable Periodic Snapshots check box.
In the Snapshot Period box, specify how frequently VR-Forces should take snap- shots.
In the Maximum Number of Snapshots in Memory box, specify how many snap- shots to keep in memory.
Snapshots are stored in memory and listed in the Scenario Snapshots dialog box. They get cleared automatically when you load a scenario or rewind a scenario and run it again. If you roll back to a snapshot and run the scenario, all snapshots later than the rollback point are deleted. You can also clear snapshots manually.
When you clear the snapshot list, VR-Forces keeps the initial snapshot so that you can still rewind the scenario.
To clear the snapshot list:
Choose File Scenario Snapshots, or on the Checkpoint Settings page, click Show Snapshots. The Scenario Snapshots dialog box opens (Figure 7-19).
Click Clear All.
Creating and Running Scenarios — Pausing a Scenario Automatically
You can specify a scenario end time (in simulation time). As the scenario progresses, the amount of time remaining is displayed in the Simulation Time Remaining Toolbar (Figure 7-22). When the scenario reaches this time it stops. You can resume the scenario by clicking the Play button.
Figure 7-22. Simulation Time Remaining Toolbar
You can set the scenario end time when you create a scenario or after you have loaded it.
The default scenario end time for new scenarios is 0 – do not pause the scenario.
To set the scenario end time for a new scenario:
Create a new scenario as described in “Creating a Scenario,” on page 7-3.
In the New Scenario dialog box, select the Advanced tab.
Specify an end time in days, hours, minutes, and seconds.
Continue the scenario creation procedure.
You can set the scenario end time for a scenario after you open it. If you set a time that is sooner than the current elapsed time, the scenario stops immediately.
To set the scenario end time for an open scenario:
Choose Simulation Set Scenario End Time. The Set Scenario End Time dialog box opens.
Specify how long you want the scenario to run.
Click OK.
Optionally, save the scenario. Remember that if the scenario is already running or has advanced and then paused, the end time is saved to a checkpoint, not the orig- inal scenario.
Batch mode allows you to run one or more scenarios multiple times, without direct action through the graphical user interface. A scenario run in batch mode runs with the parameters in the scenario file, except that you can override the random number seed.
Batch mode is “read only.” You cannot save a scenario, create simulation objects or objects, pause the scenario, or otherwise change it, while a batch is running. However, you can view the Objects List Panel, plan windows, and open informational dialog boxes. You can close a scenario that is running in batch mode and resume control of VR-Forces.
A batch mode file contains the information that VR-Forces needs to run scenarios in batch mode. Batch mode offers the following options:
Run a particular scenario multiple times.
Run a series of different scenarios (batches), each of which can be run multiple times.
Run from the command line using one back-end. If a scenario was created using multiple back-ends, you cannot run it in batch mode using this method.
Run from the VR-Forces front-end using one or more back-ends.
Generate Logger Control messages to have the MAK Logger record each simula- tion.
For each batch (one scenario run one or more times) within the batch file, you can:
Specify the length of time the simulation is to run (in real time or simulation time).
Specify the object parameter database to use.
Specify that the random number seed used be the value specified in the scenario file, a value specified in the batch file, or be computer generated.
A batch file has the file extension .bsn.
To run VR-Forces in batch mode, you create a batch file (.bsn). VR-Forces supplies a sample batch file. Use it as a model for creating your own batch files.
To create a batch file:
Create scenarios as you would any scenario. (For details, please see “Creating a Scenario,” on page 7-3.)
In a text editor, open the sample batch file provided with VR-Forces.
Save the batch file under a new name, with the file extension .bsn.
Replace the sample values with your own, as described in “Editing a Batch File,” on page 7-37.
Save the new batch file.
A batch file is written in MAK Technologies Lisp format (MTL). (For information about the MTL format, please see “MÄK Technologies Lisp (MTL) Files,” on
page A-3.) A batch file starts with parameters that affect the entire batch. Then it has a batch list, which contains one or more batches. Each batch specifies a scenario, the number of times it is to be run, and other parameters. Table 7-3 describes the parame- ters.
The following is an example of a batch file:
(scenario-batch
(use-logger-control True)
(logger-files-path "..\logger_tapes") ;; path is relative to Logger executable.
(batch-list (batch
(number-of-runs 2)
(random-number-seed 4)
(scenario-filename "..\data\scenarios\breach\breaching.scn") (sms-filename
"..\data\simulationModelSets\EntityLevel.sms")
(simulation-run-duration 0 : 0 : 0 : 30.000000) ;; simulation time
)
(batch
(number-of-runs 3) (scenario-filename
"..\data\scenarios\apache\apache_groundDB.scn") (sms-filename
"..\data\simulationModelSets\EntityLevel.sms") (run-duration 0 : 0 : 0 : 20.000000) ;; real time
)
)
)
Table 7-3: Batch file parameters
Parameter Description Scenario-batch parameters
use-logger-control Specifies whether or not to generate Logger Control
messages. Options:
False – Do not generate messages.
True – Generate messages to create Logger files for each run of each batch.
logger-files-path If use-logger-control is True, specifies the directory in which to store Logger files. The path can be absolute or relative to the Logger executable.
Batch-list parameters
Batch-list parameters
number-of-runs Specifies how many times to run the scenario in this batch run entry.
random-number-seed Optional. Overrides the random number seed in the scenario file. It specifies a random number seed as follows:
-1 – use a value generated by the computer. Values are different for each run of this batch.
Any non-negative integer – use the number specified for each run of the batch.
scenario-filename Specifies the scenario to be run in this batch run entry. The scenario can be specified as an absolute path or a path rela- tive to the directory in which the executable is located.
sms-filename Optional. Overrides the simulation model set specified by the scenario and specifies the simulation model set file to use.
simulation-run-duration Specifies the duration in simulation time that the simulation will run. It is mutually exclusive with run-duration. If both are specified, VR-Forces uses simulation-run-duration.
!
!
Specify hours, minutes, and days as integers, for example 15. Specify seconds as real numbers, for example, 15.0.
run-duration Specifies the duration in real time that the simulation will run. For example, if a scenario has a time scale set to 2 (twice real time), and a run-duration of 10 minutes, 20 minutes of simu- lation time will elapse before the batch stops running this scenario. It is mutually exclusive with simulation-run-duration.
!
!
Specify hours, minutes, and days as integers, for example 15. Specify seconds as real numbers, for example, 15.0.
To run VR-Forces in batch mode:
Start VR-Forces. If any of the scenarios you plan to run in batch mode require multiple back-ends, start the back-ends with the required site and application IDs.
If you are going to generate Logger control messages, start the MAK Logger.
Choose File Load Batch File, or click the Load Batch File button ( ) on the File Toolbar. The Load Batch File dialog box opens.
Select the batch file you want to run.
Click Open.
VR-Forces begins running the first scenario in the batch file. When VR-Forces finishes running the batch file, it closes the final scenario.
When VR-Forces runs a batch file, if it cannot load a scenario specified in the file, it skips the scenario and goes to the next batch entry in the file.
Automatic remapping is always enabled for batch mode.
If your scenarios only need one back-end, you can run a batch file from the command line.
To run a batch from the command line, use the -B parameter, with the back-end in separate mode, for example:
vrfSimDIS -s 1 -a 3001
-B “../userData/scenarios/batchfile.bsn”
The scenario begins to run automatically.
If you generate Logger Control messages, each simulation is saved individually by the Logger, with a filename in the format:
<batch_scenario_name>_<scenario_run_number>_<random_number_seed>.lgr
You can specify the directory in which you want the Logger file to be saved.
The MAK Logger does not record batch file runs if a previous recording exists. By default, the Logger does not allow you to overwrite existing files using the remote control API. So, once you record a batch run, you cannot record a subsequent run of the same batch. You can work around this problem by editing the lgrConfig.xml file to permit overwriting of Logger files. Make the following edits in the configuration file for each protocol for which you want to record batch runs:
Add the following lines to the <defaults> section:
<var name="processRemoteControl" type="bool" value="true"/>
<var name="recordRemoteControl" type="bool" value="true"/>
<var name="allowDeleteRemoteControl" type="bool" value="true"/>
Add the following lines to the <commands name="startup"> section:
<command domain="Simulation" protocol="DIS" command="SetRemoteControlSettings">
<param name="process" var="processRemoteControl"></param>
<param name="record" var="recordRemoteControl"></param>
<param name="allowDelete" var="allowDeleteRemoteControl"></param>
</command>
Use the appropriate value for the protocol attribute.
Creating and Running Scenarios — Recording VR-Forces Simulations with the MAK Data Logger
By default, when you run or pause a scenario, VR-Forces sends scenario control messages that are meaningful only to VR-Forces applications that are part of the current session. Sometimes VR-Forces users want all of the participants in a simulation, which may include non-VR-Forces applications, to know when VR-Forces runs or pauses a scenario. You can achieve this by telling VR-Forces to send standard Start/Resume and Stop/Freeze messages instead of the VR-Forces-specific messages. All of the applications that are listening for them will receive them and can respond as needed.
If you are running multiple VR-Forces sessions and you use Start/Freeze messages, all of the sessions receive them, which may defeat the purpose of having separate sessions.
To enable use of Start/Freeze messages:
Choose Settings Application. The Application Settings dialog box opens.
Select the Use Standard Start/Resume and Stop/Freeze PDUs check box.
You can use the MAK Logger to record VR-Forces simulations and then play them back for review. If you want to view a Logger file in VR-Forces (as opposed to some other MAK viewer, such as VR-Vantage Stealth), note the following considerations:
Do not load the original scenario in VR-Forces while you view the recording. Just load the terrain database that the simulation requires.
If you are using HLA 1516, do not record a simulation and then immediately play it back. Exit the applications and start a new federation. Trying to play back the file in the federation from which it was recorded can result in name reservation conflicts and applications may crash.
If a scenario includes plans that have view control messages, the Logger records them. When you play the recording, VR-Forces and other VR-Vantage applications will change view modes in response to them. This feature lets you easily create demonstra- tions that change views.
Creating and Running Scenarios — Recording VR-Forces Simulations with the MAK Data Logger
Scenario events let you provide non-simulated input to scenario participants.
Introduction to Scenario Events 8-2
Adding Content to a Scenario Event 8-5
Adding Intelligence Objects 8-8
Starting a Scenario Event 8-10
Starting a Scenario Event from a Plan 8-11
Deleting a Scenario Event 8-13
Showing and Hiding Scenario Events 8-14
Scenario Events — Introduction to Scenario Events
A scenario event represents an incident or condition that exercise participants can respond to, for example a political event, a natural disaster, or some other novel event that might require a participant to respond. VR-Forces does not simulate scenario events. Objects in a simulation do not interact with scenario events and scenario events do not affect simulation objects. Scenario events are placeholders that allow you to provide a richer simulation experience.
Events can include rich text, audio files (WAV), video (AVI) and raster files (JPG, PNG, SVG, or BMP). Use of these media allow you to expand the scope and quality of a training experience without needing to build a complicated simulation to support it. The flexibility of scenario events allows you to use them in any way that adds value to an exercise, for example, mission briefings, and video teaching points.
Figure 8-1. Scenario Event Toolbar
If you want to play MP4 video for scenario events, you must install an appropriate driver on your computer.
To create a scenario event:
Choose Simulation Scenario Events. The Scenario Event Manager opens (Figure 8-2).
Click New Scenario Event. The Create Scenario Event dialog box opens (Figure 8-3).
Figure 8-3. Create Scenario Event dialog box
Table 8-1 describes the parameters you can specify for a scenario event:
Table 8-1: Scenario event parameters
Parameter Description
Parameter Description
Event Title A short descriptive name for the event. Label The label to be displayed. (optional) Extended labels If present, fill out extended labels. (optional)
Overlay The overlay to which the event is assigned. Default: Events.
Use Location You can specify a location for an event icon to appear when the event is triggered. You can click on the map where you want the event to occur or enter a location in any of the location formats. (optional)
Ordinal Events are numbered in the sequence they are created. You can change the numbers to suit your purposes.
Event Icon Select an appropriate icon to appear on the map at the location and time of the event. This icon is also used on the Quick Launch toolbar. (optional)
Forces Select the forces you want to get the event when it occurs. You can select multiple forces.
Show on Quick Launch Toolbar
Adds the event to the Quick Launch toolbar for one-click activa- tion.
Start Specify one of the options for how the event gets triggered:
Manual. Event will be triggered manually by the scenario administrator.
Time of Day. Specify the time of day.
Linked. Specify the linking events as described in “Adding Linked Events,” on page 8-6.
Simulation Time. Specify the simulation time.
Immediate. The event starts as soon as it is created.
End Specify how the end of the event is triggered, as follows:
Manual. Ended by the scenario administrator.
Time of Day. Specify the time of day.
Duration. Specify how long the event lasts.
Permanent. The event does not end until you manually change the end type and end it.
!
!
If you trigger an event by time and the specified time is prior to the start time of the scenario, the event is triggered when the scenario starts.
Event Content Add content as described in “Adding Content to a Scenario Event,” on page 8-5.
Click Create. Your new event appears in the event list. Events may be sorted by any of the column headings.
The content for a scenario event can be text, audio, video, graphics (in BMP, JPG, SVG, or PNG), or some combination of them.
For sound and video files, you can specify files in any format that your computer supports.
To add content to a scenario event:
Create an event as described in “Creating a Scenario Event,” on page 8-3.
In the Create Scenario Event dialog box, click Event Content. The Event Contents dialog box opens (Figure 8-4).
Select the tab for the content type that you want for this event. You can have more than one type of content.
For video, picture, or audio:
Click Choose. A file selection dialog box opens.
Select the file you want to add.
Click Open.
For text:
Type the text you want in the dialog box or click Load and select a text file to load.
Format the text as desired.
Optionally, test video and audio files by clicking the Play button.
Click Close.
You can link multiple events to a single preceding event (many to one) or link one event to another linked event if your scenario requires it (one to one). You can create a linked event to trigger at any time after the preceding event it is linked to. For example, an event of a bridge being washed away could be linked to a preceding event such as reporting heavy rains, flooding, or rising river levels.
To add a link to a scenario event:
Create an event as described in “Creating a Scenario Event,” on page 8-3.
For the Start trigger, select Linked. The Edit Links button is added to the dialog box.
Click Edit Links. The Edit Links dialog box opens (Figure 8-5).
Figure 8-5. Edit Links dialog box
Click the Add button ( ). The Link to Scenario Event dialog box opens (Figure 8-6).
Select When Activated or When Concluded to indicate the relationship of the event to its linked event.
Select the event you want to link to.
Click OK.
Optionally, add additional linked events.
Specify the time delta. This is the amount of time to wait after the preceding event before triggering the linked event. If you specify multiple linked events, this is the time after all event conditions have been met.
Figure 8-7. Edit Links dialog box with links
Click OK.
Scenario Events — Adding Intelligence Objects
Intelligence objects are tactical graphics that trigger scenario events when they are detected by a simulation object. By default, intelligence objects are detected by visual sensors. However, you can configure them to be detectable by other sensors.
To add an intelligence object:
Choose Simulation Scenario Events. The Scenario Event Manager opens (Figure 8-2).
Click New Intelligence Object. The cursor changes to draw mode and the Create Intelligence Object dialog box opens (Figure 8-8).
Click where you want the intelligence object to be located, or type its location in the dialog box.
Scenario Events — Adding Intelligence Objects
Specify basic information and trigger settings as you would for a scenario event (“Creating a Scenario Event,” on page 8-3), except that instead of configuring a start event, you specify detectability.
To use only a visual sensor for detectability, select a distance in the Detectability list.
To use other sensors, specify detectability as follows:
In the Detectability list, select User Defined. The Edit Detectability button is added to the dialog box.
Click Edit Detectability. The Set Sensor Signatures dialog box opens (Figure 8-9).
Select each sensor that you want to use to detect the intelligence object.
For each sensor specify the sensor signature. (Although sensor signatures are technically unit-less, as a practical matter the sensor signature represents the distance in kilometers at which the object can be sensed.)
Click OK.
Click Create.
Scenario Events — Starting a Scenario Event
A scenario event starts based on the Start Event trigger, by a command in a plan, or manually. Regardless of how a scenario event’s trigger is set up, you can manually start an event at any time.
To start a scenario event manually:
Choose Simulation Scenario Events. The Scenario Event Manager opens (Figure 8-10).
In the Status column, click the Play button ( 
) for the event you want to start (Figure 8-10). The Event window opens (Figure 8-11).
Scenario Events — Starting a Scenario Event
You can include scenario events in plans. For example, a simulation object’s plan could have an Entity In Area condition and when that condition is satisfied, you could trigger an event such as, “The enemy has seized your headquarters!” or “Congratulations, you have seized the enemy headquarters!”
To send a scenario event in a plan:
In a plan window, choose Commands Scenario Event. The Scenario Event dialog box opens.
Select the event you want to send.
In the Operation list, select Start or Stop.
Click OK.
Scenario Events — Ending a Scenario Event
An event ends based on the End Event trigger setting, by a command in a plan, or manually.
To end a scenario event manually:
Choose Simulation Scenario Events. The Scenario Event Manager opens.
In the Status column, click the Stop 
) button for the event you want to stop (Figure 8-12).
Figure 8-12. Scenario Event Manager, Stop button
If the Status column says Active, but does not have a Stop button, this is a permanent event. To end it, you must edit the event and change the End mode to Manual. A Stop button will be displayed.
Click Close.
Scenario Events — Deleting a Scenario Event
To change the sort order of scenario events, click the heading of the column that you want to sort on.
To delete a scenario event:
Choose Simulation Scenario Events. The Scenario Event Manager opens (Figure 8-12).
Click Delete.
Scenario Events — Showing and Hiding Scenario Events
You can specify which events, if any, are displayed and whether or not the Event dialog box is displayed when an event gets triggered. The visible to force settings refer to visi- bility according to spot report settings and are based on the force availability specified when a scenario event is created or edited.
To show or hide scenario events:
Choose Settings Display. The Display Settings dialog box opens.
Select the Scenario Event Settings page (Figure 8-13).
Select an option for viewing events.
9. Target Detection and Combat Features
This chapter describes VR-Forces features related to target detection and acquisition, such as spot reports, hostility relationships, lasing, and munition damage.
Displaying Simulation Objects Based on Spot Reports 9-2
Enabling or Disabling Spot Reports 9-3
Configuring the Spot Reports Viewpoint 9-4
Configuring the Spot Reports Certainty Level 9-8
Applying Spot Reports to Tactical Graphics 9-9
Displaying Labels for Spot Reports 9-9
Using Spot Reports in Tasks 9-9
Managing Force Hostility Relationships 9-10
Changing a Force’s Hostility in a Plan 9-12
Target Detection and Spot Reports 9-15
Propulsion Noise and Sonar 9-18
Launching Counter Measures (Chaff and Flare) 9-19
Modeling Artillery Munitions 9-21
A spot report is a report by a simulation object to members of its force that it has detected a member of another force.
By default, VR-Forces displays simulation objects based on complete ground truth. That is, it shows all simulation objects in their exact location. However in real-world combat and training situations, participants rarely know where all other simulation objects are, including those in their own force. This is called the fog-of-war. VR-Forces can simulate a semblance of the fog-of-war by displaying simulation objects based on spot reports, rather than ground truth.
When you display simulation objects based on spot reports, you do not see all members of forces other than your own. You only see spot reports for other-force simulation objects that have been detected by members of your force. Spot reports are represented by icons that are similar to simulation object icons, but they do not move as simulation object icons do. Furthermore, since spot reports lose value over time as simulation objects move to different locations, VR-Forces maintains a certainty level for the loca- tion of spot reports. If a detected simulation object is not detected again for a period of time, its certainty decreases and its icon becomes increasingly transparent to show that it is less certain that the simulation object is at the reported location.
Generating spot reports can reduce the performance of the simulation engine.
When spot reports are enabled, VR-Forces does not display icons for dead simulation objects.
When you rewind a scenario, the global spot report setting persists. Spot report settings for individual simulation objects revert to the settings saved with the scenario.
You can view a video that demonstrates simulation object classification and spot reports at ./doc/vrforces_tutorialvideos.htm, or click the camera icon next to the procedure whose video you want to view.
You can enable or disable spot reports globally or per simulation object. To set spot reports for a simulation object, use the Spot Reports set data request, as described in “Spot Reports,” on page 34-41.
When you enable or disable spot reports globally, the setting is applied to all simulation objects that have not explicitly set spot reports on or off with the Spot Reports set data request. The setting persists, which allows you to set a simulation object to use the global spot report setting.
To enable or disable spot reports for all simulation objects:
Choose Settings Application. The Application Settings dialog box opens.
Select the Enable/Disable Spot Reports tab (Figure 9-1).
Figure 9-1. Spot Report Options page, Enable/Disable Spot Reports tab
Click Turn on Spot Reports or Turn Off Spot Reports. The change takes effect immediately.
The spot report viewpoint determines which simulation objects and tactical graphics are shown using ground truth and which are shown using only spot reports. You can select preconfigured viewpoints or create custom viewpoints.
!
!
If you create a simulation object for a force that is not visible based on the viewpoint setting, after you create the simulation object, it will disap- pear. Therefore, it is recommended that you show ground truth for all forces when you are creating simulation objects and tactical graphics.
When you rewind a scenario, the viewpoint configuration stays the same as in the previous run of the scenario. The global spot report setting stays the same. Entity-specific spot report settings revert to the settings saved with the scenario.
VR-Forces provides viewpoints for the friendly, opposing, and neutral forces. In each of these viewpoints, VR-Forces displays ground truth for the viewpoint force and spot reports for the other forces. For example, if you select the Friendly force viewpoint, all simulation objects in Force 1 are displayed showing ground truth. All other simulation objects are displayed only if they have been detected by a friendly simulation object that is configured to send spot reports.
When you select a preconfigured viewpoint, the check boxes in the windows in the Map View group box are automatically set to match the selected viewpoint.
To configure spot reports:
Choose Settings Application. The Application Settings dialog box opens.
Select the Spot Report Options page.
Select the Viewpoint tab (Figure 9-2).
Select an option in the Show Spot Reports from Viewpoint of Force list.
It is possible to create a custom configuration in which no objects are displayed, so think carefully about your choices.
To configure a custom viewpoint:
Choose Settings Application. The Application Settings dialog box opens.
Select the Spot Report Options page.
In the Show Spot Reports Sent From window, select the forces whose spot reports you want to display. In other words, if you are not showing ground truth for the opposing force and only want to see the opposing force simulation objects that are detected by friendly and neutral simulation objects, then select the Friendly and Neutral check boxes.
There may be cases when you want to simulate same-side fog-of-war. That is, members of a force do not know where other members of their force are unless detected by a simulation object and reported using a spot report.
To simulate same-side fog-of-war, you must edit the spot-report-generator.sysdef file. You might want to create a customized file that you can assign only to the simulation objects that you want to simulate same-side fog-of-war. (You can use the Simulation Object Editor to change the spot report systems that simulation objects use.) In the system definition file change the send-spot-reports-on-own-force parameter to True, as follows:
(spot-report-generator-system (controllers
(spot-report-generator (component-descriptor-type
"spot-report-generator-controller-descriptor")
...
(object-types-to-spot-report
(object-type 1 (1 -1 -1 -1 -1 -1 -1))
(object-type 1 (3 -1 -1 -1 -1 -1 -1))
(object-type 1 (5 -1 -1 -1 -1 -1 -1))
)
(send-spot-reports True)
(send-spot-reports-on-own-force True) (send-spot-reports-on-hostile-forces True) (send-spot-reports-on-neutral-forces True)
)
)
...
)
You can edit the system definition file by hand or in the OPD Editor. For details about the OPD Editor and the Simulation Object Editor, please see Section XI, Creating and Editing Simulation Models.
It is assumed that as time passes the validity, or certainty, of a spot report declines. To simulate this decline in certainty, VR-Forces can display the icons that represent spot reports at increasing levels of transparency. Once the initial validity period has expired, the spot report degrades over a configurable amount of time. The icon’s transparency decreases in four steps, with each step being 25% of the total time allotted for degrada- tion.
The validity period is specified by the report-resend-period parameter in the spot-report-generator.sysdef file in the SMS you are using. The default is 60 seconds.
To configure the amount of time, in seconds, over which a spot report degrades:
Choose Settings Application. The Application Settings dialog box opens.
Select the Spot Report Options page.
Specify a value, in seconds, in the Time After Spot Report Expiration Before Spot Report Is Removed box.
Figure 9-3. Spot Reports Option, Display tab
If a tactical graphic is assigned to a force, you can display it based on spot reports rather than ground truth. The same criteria are applied to their display as are applied to the display of simulation objects. For information about how to assign objects to a force, please see “Creating Tactical Graphics,” on page 39-2.
To apply spot reports to tactical graphics:
Choose Settings Application. The Application Settings dialog box opens.
Select the Spot Report Options page.
Select the Apply to Control and Tactical Graphics check box.
To display spot report labels:
Choose Settings Application. The Application Settings dialog box opens.
Select the Spot Report Options page.
In the Spot Report Labels group box, select the labels that you want to display.
You can also enable labels for spot reports on the Display Settings dialog box, Symbol Decoration Settings page.
Spot reports are listed in the Objects List Panel and other simulation object lists. Although the spot report icon in the display window may not show information about a spot report if it has not been identified, the entry in the list includes the object name. You can filter the list to only show spot reports.
You can select a spot report as a parameter in tasks that require you to select a simula- tion object. If you use a spot report in a task, VR-Forces carries out the task based on the ground truth of the reported simulation object, not the location of the spot report. For example, if you specify a spot report in the Follow Entity task, and the target simu- lation object moves after the spot report was received, the following simulation object will follow the actual location of the reported simulation object, not its location when the spot report was made.
VR-Forces categorizes simulation objects as members of a force, such as friendly, opposing, or neutral. By default, friendly forces and opposing forces are hostile to each other. Neither is hostile towards neutral forces. You can change force hostility relation- ships dynamically. This may be particularly useful if you are simulating an environment in which civilian populations become hostile to a particular force, or in which armed militias, for example, switch allegiances to other forces.
You can add new forces in the Simulation Object Editor. For details, please see “Managing the Forces List,” on page 64-22. You can change a force’s hostility in a global or individual plan. For details, please see “Changing a Force’s Hostility in a Plan,” on page 9-12.
You can change the default hostility relationships by editing the forceHostilty.mtl file for the simulation model set you are using (for example, ./data/simulationModel- Sets/<model_set>/forceHostilty.mtl).
When you change force hostility at runtime, the changes are saved as part of the scenario. The hostility relationships loaded with a scenario override the hostility rela- tionships loaded by the simulation model set's hostility file.
Hostility relationships are not reciprocal. For example if you set neutral force simulation objects to be hostile to friendly force simulation objects, that does not mean that friendly force simulation objects are hostile to neutral force simulation objects.
Target Detection and Combat Features — Managing Force Hostility Relationships
To change the force hostility matrix:
Choose Simulation Hostility Matrix. The Hostility Matrix dialog box opens (Figure 9-4). Each row in the matrix lists the hostility relationships between that row’s force and all of the other forces (represented by color-coded columns).
For each row in the matrix, select the check boxes in the columns for the forces that you want this force to be hostile towards. Clear the check boxes for forces that you do not want it to be hostile towards.
Click OK.
To change a force’s hostility in a global or local plan:
Open a global plan or an individual plan.
Choose Commands Change Hostility. The Change Hostility dialog box opens (Figure 9-5).
In the Force to Change list, select the force whose hostility you want to change.
In the To Force list, select the force towards which you want to change hostility.
Select the new force relationship (New Stance), either Friendly or Hostile.
Click OK. The command is added to the plan.
CID Level 0 – not detected.
CID Level 1 – Detected: the simulation object is detected, but only its plat- form is known, for example, ground.
CID Level 2 – Classified: the simulation object’s category is known, for example, tank.
CID Level 3 – Identified: the simulation object’s category and subcategory are known, for example M1A2.
CID Level 4 – Full Knowledge: all visible information about the simulation object is known.
CID levels are assigned based on the distance to the detected simulation object and the length of time that the simulation object has been in contact. You can configure these values in the detection tables (./data/simulationModelSets/<model_set>/vrfSim/detec- tion/*.csv). For details about these configuration files, please see “Detection Tables,” on page 71-14.
By default, simulation objects do not fire at a detected hostile simulation object until it achieves the Identified level. You can configure this behavior by changing the detection- level-to-set-hostility parameter in the simulation object’s sensor system.
Figure 9-6 shows a series of screen captures of a simulation object as its CID level is advanced from Classified through Identified. In this scenario, spot reports are enabled. Therefore, when a simulation object is detected, it is displayed with a
yellow icon, rather than the normal color for the force. It is not given the correct force color until the detected simulation object is CID level Identified.
You can view videos that demonstrates simulation object classification and spot reports at ./doc/vrforces_tutorialvideos.htm, or click the camera icons in previous paragraphs.
Classified
Identified
Figure 9-6. Simulation object classification and display when spot reports are enabled
Simulation object detection and classification can be enhanced by enabling spot reports. Detected simulation objects are assigned CID levels based on length of contact and distance from the detecting simulation object. In some cases, such as a fixed-wing aircraft flying quickly over a battlefield, or a simulation object that is at the farthest point of its range from a target, contact might not be sufficient to advance to the Iden- tified CID level. In such cases, even though the simulation object is technically capable of firing on the target, it might not do so because the CID level is not high enough.
If spot reports are enabled, the classification of simulation objects in the spot reports that a simulation object receives is combined with the directly sensed information. Therefore, if a simulation object classifies a target at a low CID level, but it receives a spot report that classifies the target at a high CID level, it can fire on the target based on the CID level in the spot report. For example, as noted in the previous paragraph, a fixed-wing aircraft is unlikely to maintain contact with a ground-based simulation object long enough to elevate its CID level to Identified. However, if a member of its force on the ground identifies the target and sends out a spot report indicating CID level 3 or 4, when the fixed-wing aircraft receives the spot report, it can add the target to its target list.
A laser-guided missile launcher must be able to see a laser spot and an appropriate target before it fires. If the missile loses the laser spot before it hits the target, it tracks to the last known laser spot.
By default, entities that have laser-guided missiles are configured for autonomous lasing. This means that they can lase targets and fire at them without outside interven- tion (for example, using the Lase Target task). Entities with autonomous lasing enabled identify and fire at targets independently, just like entities that use conventional muni- tions.
You can synchronize the laser codes of the lasing entity and the firing entity by setting them for each entity with the Laser Code set data request, or you can let VR-Forces synchronize the codes with the Synchronize Laser Code set data request. For details, please see “Laser Code,” on page 34-26 and “Synchronize Laser Code,” on page 34-43.
Target Detection and Combat Features — Using Sonar
VR-Forces simulates active and passive sonar. Entities can be configured with three types of sonar sensor systems: Active Sonar, Passive Sonar, and Sonar. The Sonar system includes both active and passive sonar. Both types of sonar use the VR-Forces sensor signature mechanism. The signatures are different, reflecting the different chances of detecting entities using the two types of sonar.
Passive sonar has the following characteristics:
Sonar can be dipped at a depth other than that of the entity.
If an entity is moving faster than a specified speed, passive sonar does not work.
Sonar takes into account thermocline data. Thermoclines are layers of water that have different temperatures and, therefore, different density. Sound transmission varies as it passes through the thermocline. In VR-Forces sonar effectiveness is reduced as it passes through thermocline boundaries. For more information, please see “Setting the Thermocline,” on page 11-22.
If an entity is publishing propulsion noise, it can affect its detectability by passive sonar.
Active sonar has the following characteristics:
Active sonar should acquire targets more quickly than passive sonar.
If an entity has an active sonar system enabled, it is more easily detected by passive sonar systems.
Entities with an active sonar that is enabled publish Underwater Acoustics PDUs.
Entities can have multiple active sonar modes, similar to radar modes, using emitter beams. For details about configuring emitters, please see “Configuring Emitters,” on page 74-2.
Active sonar detects targets within the range of its emitter beams, but without regard to the direction of the beams.
Active sonar ignores propulsion noise and the presence of active sonar on the target.
!
!
RPR FOM 1.0 does not support active sonar. If you try to create an entity that has an active sonar system, the entity will not be created and a warning will be sent to the console. If you try to load a scenario that has such an entity, it will not be created.
Sonar only works in water. Therefore rotary-wing entities with sonar systems must set their depth in order to sense anything.
Target Detection and Combat Features — Using Sonar
If an entity is generating propulsion noise, it is easier to detect using passive sonar. VR- Forces publishes propulsion noise for surface and subsurface entities. If the power plant for an entity is turned off, it does not publish propulsion noise. To turn propulsion noise on or off, change the power plant appearance (for details, please see “Appearance,” on page 34-10) or set the power-plant-active parameter in the propulsion-noise-generator component of the entity’s movement system in the OPD Editor.
VR-Forces publishes three propulsion noise values:
Current Shaft RPM, calculated as current speed * speed-to-rpm- factor.
Ordered Shaft RPM, calculated as ordered speed * speed-to-rpm- factor.
Shaft RPM Rate of Change, calculated as current acceleration * acceleration-to-rpm-factor.
The values for current speed, ordered speed, and current acceleration are the current values for the entity. The values for speed-to-rpm-factor and acceleration-to-rpm-factor are taken from the speed-to-rpm-factor and acceleration-to-rpm-factor parameters in the propulsion-noise-generator component of the entity’s movement system.
When a target is being detected by passive sonar, if it is publishing propulsion noise, its calculated RPM is compared to a nominal RPM (default 100) to generate a sensor signature modifier. For example, if an entity is publishing an RPM of 80, its signature is scaled by 0.8. If its RPM is 150, the signature is scaled by 1.5.
!
!
RPR FOM 1.0 does not support propulsion noise. If you try to create an entity that has propulsion noise enabled, the entity will not be created and a warning will be sent to the console. If you try to load a scenario that has such an entity, it will not be created.
Target Detection and Combat Features — Launching Counter Measures (Chaff and Flare)
Fixed-wing and rotary-wing entities can launch counter measures (chaff and flare) when they are targeted by air-to-air and ground-to-air missiles. By default, entities launch counter measures automatically based on settings in the countermeasures.sysdef file.
When an aircraft detects a hostile missile within a specified range, it determines the type of missile and looks up the type of counter measures to use in the USCounterMea- suresTable.asl or CISCounterMeasuresTable.asl table.
Figure 9-7 shows a friendly force fighter launching counter measures against an aphid missile.
2D 3D
Figure 9-7. Counter measures (flare)
You can disable automatic counter-measures with the Counter Measures Auto Launch set data request. You can also launch counter-measures with the Launch Counter Measures task. The Launch Counter Measures task is not an exclusive task, so it does not interfere with the entity’s current task. For details about the task and set data request, please see “Launch Counter Measures,” on page 28-13 and “Counter Measures Auto Launch,” on page 34-13.
Target Detection and Combat Features — Launching Counter Measures (Chaff and Flare)
You can configure the behavior of automatic counter measures in the counter-measures- launcher.sysdef and cis-counter-measures-launcher.sysdef files (in ./data/simulationModel- Sets/EntityLevel/vrfSim/systems/other). Table 9-1 describes the parameters that you might want to change.
Table 9-1: Counter measure launcher parameters
Parameter Description
Parameter Description
auto-launch-enabled True Enables or disables automatic launching of counter
measures.
auto-launch-range The range within which an entity will detect missiles against which to launch counter measures.
auto-launch-reset-time The amount of time, in seconds, an entity will wait
before launching additional counter measures.
auto-launch-default-resource The default counter measure to use.
auto-launch-number-of-resources The number of counter measures to launch for each
launch sequence.
counter-measures-select-table-file The counter measures selection table to use to deter-
mine which counter measures to fire for a particular missile.
Target Detection and Combat Features — Modeling Artillery Munitions
VR-Forces models artillery in two ways – direct fire and indirect fire. Artillery entities, such as howitzers use a direct fire model. The artillery entity is modeled and the muni- tions it fires are modeled. Indirect fire simply models artillery barrages within an area. For details about indirect fire, please see Chapter 10, Indirect Fire, Ballistic Missiles, and Munition Detonations.
By default, when an artillery entity fires, VR-Forces models the munition. Munitions are not affected by wind speed or friction. VR-Forces can also model artillery without modeling the munition. In this case, it just publishes a fire event and detonation event. Modeling munitions requires more computer resources than not doing so. Therefore, in large simulations you may want to disable modeling of munitions.
To disable modeling munitions, in the indirect-fire-actuator, set the simulate-munition
parameter to false. For example, in the OPD Editor:
Select the Systems List tab.
Select the M284 155mm Cannon.
Select the Components tab.
Expand the Actuators list.
Select M284-cannon.
Change the value for the simulate-munition parameter.
Target Detection and Combat Features — Modeling Artillery Munitions
10. Indirect Fire, Ballistic Missiles, and Munition Detonations
This chapter explains how to create and edit indirect fire events and ballistic missiles. These features are only supported in entity-level scenarios.
Introduction to Indirect Fire 10-2
Creating an Indirect Fire Event 10-3
Editing Indirect Fire Events 10-6
Deleting Indirect Fire Events 10-6
Configuring Indirect Fire Event Default Values 10-7
Firing Ballistic Missiles 10-8
Editing Missile Target Events 10-10
Deleting Missile Target Events 10-10
Creating Munition Detonations 10-11
The indirect fire feature allows you to create, configure, and schedule indirect fire events. Indirect fire events are not associated with a particular simulation object. VR- Forces does not model the launcher or trajectory of the munitions. Indirect fire results in one or more salvos of one or more rounds in or near a designated area of the terrain. Figure 10-1 illustrates indirect fire within an indirect fire area.
Figure 10-1. Indirect fire event
Indirect fire types are configured in ./data/simulationModelSets/EntityLevel/indirectArtil- leryTypes.mtl.
i Indirect fire is not supported in aggregate-level scenarios.
When you create an indirect fire event, you specify an area in which the event is to take place, the parameters of the event, and a starting time. The area in which an indirect fire event takes place is a tactical graphic and is listed on the Environmentals tab of the Objects List Panel.
To create an indirect fire event:
Choose Simulation Munition Targets. The Munition Target Settings dialog box opens (Figure 10-2).
Figure 10-2. Munition Target Settings dialog box, Indirect Fire page
Click New. The cursor changes to create mode and a tab for the Create Indirect Fire dialog box is added to the window.
Draw an ellipse on the map to specify the area of the fire event:
Click to set the center of the ellipse. A center point is set and a small circle is displayed with a vertex indicator at the bottom of the circle.
Drag the mouse up or down and click to set the height of the ellipse. A vertex indicator is added to the left side of the circle.
Drag the mouse left and right and click to set the width of the ellipse (Figure 10-3).
Optionally, you can specify the properties of the ellipse in the Create Indirect Fire dialog box.
Click the tab to display the Create Indirect Fire dialog box (Figure 10-4).
Type a name for the event in the Name text box, or accept the default name (Indi- rect Fire n).
Optionally, specify a layer for the event. (If there are no layers in the scenario, one will be created when you click Create to create this indirect fire event.)
Configure the parameters of the fire event, as follows:
Select the detonation start time. The options are:
Immediate. Indirect fire begins immediately.
Wait for Activation. The indirect fire area is created in the inactive state. Indi- rect fire begins when an Activation set data request activates the area. This lets you activate indirect fire manually or from a plan.
At Simulation Time. The simulation time at which you want the munition to start firing.
In the Number of Salvos box, enter the number of salvos you want to fire.
In the Rounds Per Salvo box, enter the number of rounds you want to fire for each salvo.
In the Scatter Time box, enter the length of time for each salvo. The rounds in each salvo will be detonated at random times within this time period.
If you specified more than one salvo, in the Time Between Salvos box enter the amount of time you want to pass between each salvo.
Optionally, specify an altitude above the terrain that the rounds should detonate at.
Select the munition type in the Munition Type list.
Click Create. The Indirect Fire event is added to the list (Figure 10-5). The area is added as an object on the Indirect Fire layer on the Overlays tab of the Objects List Panel (unless you chose a different layer).
Figure 10-5. Indirect Fire page with indirect fire event
You can edit the properties of an indirect fire event. You can also directly manipulate the area that specifies the event.
To edit an indirect fire event:
Choose Simulation Munition Targets. The Munition Target Settings dialog box opens.
Select the Indirect Fire page (Figure 10-5).
Select the indirect fire event that you want to edit.
Click Edit. The Edit Indirect Fire dialog box opens.
Change the properties that you want to change.
Click OK.
To delete an indirect fire event:
Choose Simulation Munition Targets. The Munition Target Settings dialog box opens (Figure 10-2).
Select the Indirect Fire page (Figure 10-5).
Select the indirect fire event that you want to delete.
Click Delete.
Click Close.
You can configure a set of default values that get applied to the Create Indirect Fire dialog box.
To configure default values for indirect fire events:
Choose Settings Display. The Display Settings dialog box opens.
Select the Indirect Fire Settings page (Figure 10-6).
Set the parameters to the desired default values.
Click Close.
VR-Forces supports firing of ballistic missiles, including multistage missiles. The trajec- tory of a missile is determined by a series of coordinates in a comma-separated values (CSV) file. VR-Forces includes some sample CSV files. VR-Forces users are responsible for creating their own files if they want missiles to fly with different characteristics.
You fire a ballistic missile by specifying a target and choosing a missile type. The charac- teristics of the missile type are specified in the Simulation Object Editor. A missile launches at the same altitude as the target point at a distance determined by the CSV file. Therefore, if a target point is placed at or near the ground, it is possible that due to variations in the terrain, the launch location could be underground. Once the missile launches, it follows the trajectory contained in the CSV file that it is configured with. It detonates when it reaches the target point. For details about configuring missiles, please see “Configuring Ballistic Missile Movement,” on page 65-48.
i Ballistic missles are not supported in aggregate-level scenarios.
To fire a ballistic missile:
Choose Simulation Munition Targets. The Munition Target Settings dialog box opens (Figure 10-2).
Select the Missile Target page (Figure 10-7).
Figure 10-7. Munition Target Settings dialog box, Missile Target page
Click New. The cursor changes to a cross-hair.
Click the location where you want the missile to hit. The Create Missile Target dialog box opens (Figure 10-8).
Indirect Fire, Ballistic Missiles, and Munition Detonations — Ballistic Missiles
Optionally, specify the parameters for the target. In particular, set the following parameters:
Name. The name of the target point.
Launch Time. The simulation time at which the missile will be launched.
Incoming Heading. The heading, relative to the target, from which the missile will be launched.
Missile Type. An option from the list.
Click Create. The missile event is listed in the Missile Target window.
You can edit the properties of a missile target event. You can also directly manipulate the target point.
To edit a missile target event:
Choose Simulation Munition Targets. The Munition Target Settings dialog box opens (Figure 10-2).
Select the Missile Target page (Figure 10-7).
Select the missile fire event that you want to edit.
Click Edit. The Edit Missile Target dialog box opens.
Change the properties that you want to change.
Click Update.
To delete a missile target event:
Choose Simulation Munition Targets. The Munition Target Settings dialog box opens (Figure 10-2).
Select the Missile Target page (Figure 10-7).
Select the missile fire event that you want to delete.
Click Delete.
Click Close.
i You can also simply delete the target point from the terrain.
Indirect Fire, Ballistic Missiles, and Munition Detonations — Creating Munition Detonations
When weapons fire munitions, they detonate and cause damage to simulation objects, terrain, or both. You can also manually create munition detonations. They have the same effect as the simulated munitions they represent.
To create a munition detonation:
Choose Create Munition Detonation. The Create Detonation dialog box opens, as if you were creating a simulation object or tactical graphic. The cursor changes to a red cross-hair.
If you want to use the currently configured detonation type and result, click on the terrain where you want the detonation to occur. You can continue to click to create more detonations while in this mode.
If you want to change the munition type or result:
In the Munition Type list, select the type of munition you want to detonate.
In the Result list, select the type of detonation that you want to occur.
Optionally, specify the location for the detonation.
Click on the terrain where you want the detonation to occur. Click as many times as you want.
To exit detonation mode, close the Create Detonation dialog box or press Esc.
Indirect Fire, Ballistic Missiles, and Munition Detonations — Creating Munition Detonations
11. Setting Environment Conditions
This chapter explains how to set the time of day and weather conditions.
Introduction to Environment Conditions 11-2
Setting the Date and Time of Day 11-2
Choosing the Illumination Model 11-4
Specifying the Environment Conditions 11-5
Adding an Environment Condition 11-7
Editing an Environment Condition 11-7
Deleting an Environment Condition 11-8
Setting Weather Conditions 11-8
Setting the Wind Speed and Direction 11-9
Setting the Ambient Air Temperature 11-10
Setting Visibility (Fog) 11-10
Specifying Precipitation Type and Intensity 11-12
Creating Local Weather Zones 11-13
Editing a Weather Zone’s Environment 11-15
Configuring Marine Conditions 11-16
Configuring Marine Conditions 11-17
Enabling Tidal Stream Wakes 11-19
Configuring Breaking Waves 11-21
Setting Environment Conditions — Introduction to Environment Conditions
Date and Time and Weather are options on the Commands menu in plans.
You can set the date, time zone, and time of day.
Time zone: You can change the time zone displayed in the Environmental Settings toolbar to any zone that you want. If you change the time zone in the Environment Conditions dialog box, the time displayed in the Environment Settings Toolbar changes to the current time for that time zone. However, the time at a given loca- tion on the earth does not change. The illumination at a location therefore does not change when the time zone displayed in the toolbar changes. Since the time zone at a location may not be the same as the time zone displayed in the toolbar, the illumination at that location may not match the time displayed in the toolbar.
Time of day: The time of day advances as simulation time advances. However, they are not directly tied to each other. For example, if at the start of a simulation (simu- lation time 0:00:00:00), you set the time of day to 10:00 AM, after eight hours of simulation time passes, the time of day will be 6:00 PM. However, you could just as easily set the initial time of day to some other time or change it at will during the course of the simulation. These changes would not affect the elapsed simulation time in any way. They would just change the starting point for the advance of the time of day.
Setting Environment Conditions — Setting the Date and Time of Day
To set the date:
Choose Simulation Environment Settings, or click the date on the Environment Settings Toolbar. The Environment Settings dialog box opens.
Select the Date and Time page (Figure 11-1).
To change the month, click the right or left arrows, or click the month and select a month from the list.
To change the year, click the right or left arrows, or click the year and type in a year or use the spin controls to select a value.
To specify the date, click on the date in the calendar.
Setting Environment Conditions — Setting the Date and Time of Day
As time advances, the time displayed on the Environment Settings Toolbar changes. The time of day setting is independent of simulation time. The default time zone is Greenwich Mean Time. You can change the time zone to the local zone or any of the zones in the Time Zone list.
i If you want to set the time of day and time zone, set the time zone first.
To set the time of day:
Choose Simulation Environment Settings, or click the date on the Environment Settings Toolbar. The Environment Settings dialog box opens.
Set the time of day by changing the value in the Current Time box or by adjusting the Hour and Minute sliders.
Select the time zone in one of the following ways:
Select a time zone in the Time Zone list.
Select Use Local Time Zone. The time zone set for your computer is used.
To specify the illumination model:
Choose Simulation Environment Settings, or click the date on the Environment Settings Toolbar. The Environment Settings dialog box opens.
Select or clear the Use Day/Night Illumination Model check box.
VR-Forces has a set of preconfigured environment conditions. Each environment condition has settings for:
Weather:
Wind speed and direction.
Cloud cover.
Visibility.
Precipitation type and intensity.
Fog height and color.
Marine:
Sea swell.
Sea state.
Surface transparency.
Underwater visibility.
Choppiness.
Surge depth.
Conditions range from clear to stormy and let you quickly set the weather without needing to adjust all the various weather parameters. However, if you want to, you can change any of the individual weather parameters. Changing a weather or marine setting does not affect the saved settings unless you specifically overwrite them.
You can save and import environment settings. Environment settings support the stan- dard VR-Forces settings behaviors, as described in “Managing VR-Forces Settings,” on page 4-21.
You can add your own environment conditions.
Setting Environment Conditions — Specifying the Environment Conditions
To specify an environment condition:
Choose Simulation Environment Conditions. The Environment Conditions dialog box opens.
Select the Weather page (Figure 11-2).
In the Apply Environment Condition list, select the condition you want.
If you add an environment condition, it gets added to the Apply Environment Condi- tion list.
To add an environment condition:
Choose Simulation Environment Conditions. The Environment Conditions dialog box opens.
Change the weather settings to the ones you want for the new condition.
Click the Add button ( ). The Name an Environment Condition dialog box opens.
Type a name for the new condition.
Click OK.
You can change the settings for an environment condition. Editing a condition essen- tially means overwriting a condition with the current set of weather and marine condi- tions.
To edit an environment condition:
Choose Simulation Environment Conditions. The Environment Conditions dialog box opens.
Optionally, in the Apply Environment Condition list, select a condition you want to use as your starting point.
Change whatever conditions you want.
Click the Edit button 
). The Select an Environment Condition dialog box opens.
In the Select Name list, select the condition you want to overwrite.
Click OK.
If you delete one of the built-in environment conditions, you can restore it from the factory settings.
To delete an environment condition:
Choose Simulation Environment Conditions. The Environment Conditions dialog box opens.
Select the Weather page (Figure 11-2).
Click the Delete button ( ). The Select an Environment Condition dialog box opens.
In the Select Name list, select the condition you want to delete.
Click OK.
You can set the following weather conditions:
Cloud cover.
Visibility.
Precipitation.
Wind speed and direction.
Ambient air temperature.
When you specify weather, the back-end sends out state updates with these conditions. Simulation objects respond to them only if their model has the ability to do so.
You can set the wind speed and direction. If you do not specify the sea state manually, it is set based on the wind conditions. The maximum wind speed that you can set is 360 km/h.) The wind direction affects the angle at which precipitation falls. Wind speed and direction affect particle systems (dust clouds, smoke, and so on).
To set wind speed and direction:
Choose Simulation Environment Conditions. The Environment Conditions dialog box opens.
Select the Weather page (Figure 11-3).
Drag the Wind Direction indicator to the desired compass point or select an option from the list.
Drag the Wind Speed slider or enter a value in the box.
You can specify the ambient air temperature. VR-Forces does not do anything with this information. It is sent over the network for the use of applications that need to model air temperature.
To set the ambient air temperature:
Choose Simulation Environment Conditions. The Environment Conditions dialog box opens.
Drag the Ambient Air Temperature slider or enter a value in the box.
The visibility setting determines the denseness of the fog effect, which determines how far you can see.
To set visibility:
Choose Simulation Environment Conditions. The Environment Conditions dialog box opens.
Adjust the Visibility slider or enter a value in the box.
You can set the fog height and color. The fog height affects how much sky the observer can see when looking up from ground level. For example, if you set the fog height to 50m and look up, you will see some amount of sky above you, and to the sides it will be very gray. If you then set it to 10m and look up, you will see mostly blue sky above you, but still quite a bit of gray to the sides.
Fog settings are not modeled in the back-end. Therefore, they are not available when you set weather conditions in a plan.
To configure fog:
Choose Simulation Environment Conditions. The Environment Conditions dialog box opens.
In the Weather section of the page, click Advanced. The dialog box expands to show options for fog.
To set the fog height, adjust the slider or enter a value in the box.
To set the fog color:
Click the color swatch. A color picker dialog box opens.
Select the color you want to apply to the fog. It is applied immediately, so you can easily see the effect of the new color and change it if you want to.
Click OK.
VR-Forces supports display of rain and snow. You can configure the intensity of precip- itation.
Precipitation has no effect on the simulation. It is only a visual effect. Snow does not accumulate.
To specify the precipitation type and intensity:
Choose Simulation Environment Conditions. The Environment Conditions dialog box opens.
Select a Precipitation Type. If you select rain or snow, the Precipitation Intensity setting becomes editable.
Adjust the Precipitation Intensity slider or enter a value in the box. The range is 0% through 100%.
To specify the cloud cover:
Choose Simulation Environment Conditions. The Environment Conditions dialog box opens.
Select an option from the Cloud Cover list.
You can create local weather zones. Each zone can have different weather conditions and simulation objects can respond to those conditions as they move from zone to zone.
Weather zones can be boxes, free form areas, circles, and ellipses. You can create them from the Hazards/Obstacles palette just like you would create the comparable tactical graphics and you can create box weather zones from the Environment Conditions dialog box, Local Weather Zones page. (For details about creating different types of tactical graphics, please see “Placing Objects,” on page 16-11, “Drawing Circles and Ellipses,” on page 39-3, and “Drawing Boxes,” on page 39-3.)
Weather zones have a priority. If two zones overlap and one has a higher priority than the other, a simulation object in the overlapping area responds to the weather condi- tions in the higher priority zone. If overlapping zones have the same priority, the one that gets discovered first on the network is used.
By default, weather zones are placed on the Weather overlay. Weather zones display a graphic that represents the weather conditions. Figure 11-4 illustrates a weather zone set to the Thunderstorm environmental condition. You can move and resize them just as you can move and resize other tactical graphics.
To create a local weather zone from the Local Weather Zones page:
Choose Simulation Environment Conditions. The Environment Conditions dialog box opens.
Select the Local Weather Zones page (Figure 11-5).
Setting Environment Conditions — Creating Local Weather Zones
Click New. A weather zone is added to the scenario and the Create Weather dialog box opens.
The default size for a weather zone is 100,000 meters per side, so on small terrains, the zone might cover the terrain. If this is a problem, edit the Length and Width in the Create Weather dialog box to reduce it to a manageable size.
Optionally, edit the various parameters for the weather zone. In particular, select an environmental condition or edit the environment to specify the conditions you want to apply to this weather zone. For details about editing the environment, please see “Editing a Weather Zone’s Environment,” on page 11-15.
Click Create.
On the Local Weather Zones page, select the Show Weather Areas Filled check box to fill all weather zones. Clear the check box to show weather zones as outlines.
i You can also create weather zones from the Hazards/Obstacles Palette.
You can edit a weather zone’s environment when you create it or after you create it. You can assign it one of the preconfigured environmental conditions or change individual environment settings. For details about preconfigured environmental conditions, please see “Specifying the Environment Conditions,” on page 11-5.
To edit a weather zone’s environment:
Do one of the following:
In the Create Weather dialog box, click Edit Environment. The Weather dialog box opens (Figure 11-6).
On the Local Weather Zones page of the Environment Conditions dialog box, select the weather zone you want to edit and click Edit Weather Conditions. The Weather dialog box opens.
Change weather conditions as desired. They are the same as those on the Weather page of the Environment Conditions dialog box. For details, please see “Setting Weather Conditions,” on page 11-8.
Click OK.
VR-Forces supports a variety of dynamic ocean effects (Figure 11-7), including:
Douglas Sea State. This includes wind waves (wind sea), swell character, and the directions of each. VR-Forces allows each to be separately configured.
Wave chop.
Surface transparency. The ability to see through the water from above sea level.
Underwater visibility. The ability to see underwater.
Swell.
Tidal current speed and direction. If tidal stream wakes are enabled, they are auto- matically applied to streamed buoys and beacons.
i Enabling dynamic ocean effects can affect performance.
Marine effects can reduce performance.
To enable marine effects, choose Observer Dynamic Ocean.
The preconfigured environment conditions include marine conditions. You can also customize the marine settings at any time.
To configure marine effects:
Choose Simulation Environment Conditions. The Environment Conditions dialog box opens.
Select the Weather page (Figure 11-3).
Figure 11-8. Weather page
Change settings as desired. The settings are described in Table 11-1.
Table 11-1: Advanced marine settings
Parameter Description
Parameter Description
Sea Swells The amount of rise and fall of waves independent of wind. Choose from 10 fixed swell states. You can also set the compass direction from which swells originate.
Sea State Determined by the wind direction and speed or set manu- ally. If manual, one of the swell states for the Douglas sea state scale. You can also set the compass direction from which sea state originates.
Advanced Parameters
Advanced Parameters
Surface Transparency The depth at which VR-Forces begins to apply transpar-
ency to the water surface if the terrain has bathymetry or underwater polygons. This setting helps reduce Z-fighting along the shoreline. It does not mean that you can see some distance into the water when the observer is over deep water. The maximum value represents transparency to 500 meters.
Underwater visibility The distance you can see underwater if the observer is
underwater.
Choppiness The percentage of turbulence on the water.
Surge depth When bathymetry data is present, this is the depth of the
water at which full storm effects take place. As the water gets shallower, it gets calmer.
Tidal Current Speed The speed of the tidal current. This affects the display of
tidal wakes on buoys and beacons. Default: 0.
Tidal Current Direction The direction of the tidal current flow. This affects the
display of tidal wakes on buoys and beacons.
Tidal stream wakes create wake effects around buoys and beacons based on the move- ment of the tides. Tidal stream wakes are supported as stand-alone models. They are automatically attached to streamed buoys and beacons. VR-Forces includes wake models for each of the supported buoy and beacon models. They are named for the buoy or beacon type they support, for example, BuoysPillarWake or BeaconsLattice- Wake. You may want to edit the wakeLength parameter to provide the best visuals for your terrain.
Tidal stream wakes are disabled by default.
Even if tidal stream wakes are enabled, you will not see any wakes unless you also specify a tidal current, which is 0 by default. For details about setting tidal current, please see “Configuring Marine Conditions,” on page 11-17.
To enable or disable tidal stream wakes:
Choose Settings Display. The Display Settings dialog box opens.
Select the Ocean Settings page (Figure 11-9).
Select or clear Enable Tidal Stream Wakes.
To set ocean quality:
Choose Settings Display. The Display Settings dialog box opens.
Select one of the Ocean Visual Quality options.
VR-Forces can simulate the effect of waves breaking along the shore line. This feature uses shapefile data that defines the direction of the breaking waves. The MAK Earth (online).mtf terrain includes sample data for breaking waves. To see it, view the island of Oahu, Hawaii.
You can set the amplitude of breaking waves. By default, the amplitude is 0.
This is considered an experimental feature. It may be useful, but may affect performance.
To configure breaking waves:
Choose Settings Experimental Features. The Experimental Features dialog box opens (Figure 11-10).
Adjust the Breaking Waves Amplitude slider or type a value in the box. The maximum value is 10.0.
Setting Environment Conditions — Setting the Thermocline
Thermoclines are layers of water that have different temperatures and, therefore, different density. Sound transmission varies as it passes through the thermocline. In VR-Forces, sonar effectiveness is reduced as it passes through thermocline boundaries. By default, VR-Forces does not set any thermoclines. You can specify the depth of up to five thermoclines.
To specify a thermocline:
Choose Simulation Environment Conditions. The Environment Conditions dialog box opens.
Select the Thermoclines page (Figure 11-11).
For each thermocline that you want to specify, type or select a value in the depth box and the permeability box.
This chapter describes the files that get created when you create a scenario.
Specifying Pathnames for Scenario Files 12-7
Changing the Terrain Database for a Scenario 12-8
Editing the Order of Battle File 12-10
Saving Default Parameters to the Order of Battle File 12-10
The Scenario Extras File 12-10
Temporary Scenario Directories 12-11
Scenario Files — Introduction
The scenario file, named scenario_name.scn, lists the locations of the other scenario files, the terrain database, and the simulation model set file, and sets several param- eters for the scenario.
The order of battle file, named scenario_name.oob, stores identification and state information for simulation objects, control objects, and published tactical graphics.
The object map file (scenario_name.omp) maps objects to the back-ends on which they were created.
The plan file (scenario_name.pln) stores individual plans and global plans.
The scenario extras file (scenario_name.xtr) lists the forces that each force is hostile to and it stores spawn pattern templates.
The scripts file (scenario_name.spt) stores scenario-specific scripts.
The overlay file (scenario_name.ovl) lists tactical graphics that are not published. Published tactical graphics are in the order of battle file.
The selection groups file (scenario_name.sgr) stores the selection groups in the scenario and their members.
The saved views file (scenario_name.osrx) stores observer views, if any. It can also specify a startup view.
The scenario-specific GUI settings file (scenario_name.gui_settings) contains GUI settings that only apply to this scenario.
By default, scenarios are saved in a compressed zip archive with the extension .scnx. If you examine a compressed scenario file in an unzipping application, you will see that it contains the individual files described in the previous paragraphs.
For the most part, you will not want to edit scenario files by hand. In some cases, we recommend that you not edit them. However, this chapter explains how to edit them if you need to.
When you create a scenario, you can set its parameters in the New Scenario dialog box (Figure 12-1). Thereafter, you cannot edit scenario parameters in the front-end except for the scenario description and the option to attach components to remote simulation objects. However, you can edit them in a text editor.
Figure 12-1. New Scenario dialog box
The default values for scenario settings in the New Scenario dialog box are drawn from the file ./appData/settings/vrfGui/default-scenario.tmpl. If you want to change the default settings, you can edit that file.
A typical scenario file looks like the following (assume a scenario file called mysce- nario.scn):
(Scenario
(Component-Attachment 0) (Component-Attachment-Table "")
(Terrain-Database "..\userData\terrains\Ground-db.mtf") (Gui-Terrain-Database "..\userData\terrains\Ground-db.mtf") (Order-Of-Battle "myscenario.oob")
(Scenario-Scripts "myscenario.spt") (Plan "myscenario.pln")
(Overlay "myscenario.ovl") (SelectionGroups "myscenario.sgr") (Object-Map "myscenario.omp") (Scenario-extras "myscenario.xtr") (time-multiplier 1.000000)
(auto-reorganize False) (random-number-seed 0)
(frame-mode "variable-frame") (frame-time 0.100000)
(run-duration-time 0)
(sim-time 0.000000) //no loner used
(exercise-start-time 0.000000) // no longer used (additional-opds )
(Simulation-Model-Set-Files "../data/simulationModelSets/EntityLevel.sms")
(scenario-name "myscenario” (scenario-data
(Create_Global_Dynamic_Terrain "1")
(Create_Global_Environment "1") (DefaultObserverView "1 - Absolute") (GuiObserverViews "myscenario.osrx") (GuiScenarioSettings "myscenario.gui_settings") (Language "en")
(ScenarioDescription "Some text that describes the scenario.") (ScenarioExtentInformation "-2.81258e+006,-4.33259e+006,
3.72903e+006,938.957")
(Set_Scenario_Start_Time_At_Local_On_First_Object_Creation "36000")
(UseDayNightModel "1")
)
(version 3.100000)
)
Paths in the scenario files are relative to the application directory, for example, ./bin64.
The Starting Time of Day is stored in the order of battle file, not the scenario file.
The parameters in a scenario file are as follows:
Component-Attachment specifies whether or not attachment of components to remote simulation objects is allowed in the scenario. The options are:
0: no component attachment.
1: the first back-end manages all remote components.
2: remote component attachment is load-balanced on all back-ends.
–
Although you can set this value in the New Scenario and Load Scenario dialog boxes, it is not saved in the scenario file. To force a specific value, you must edit the scenario file.
Component-Attachment-Table specifies the component attachment table to use if attachment of components to remote simulation objects is allowed.
Terrain-Database specifies the terrain database to be loaded by the back-end.
Gui-Terrain-Database specifies the terrain database loaded in the front-end.
Order-Of-Battle specifies the order of battle file.
Scenario-Scripts specifies the file that has scenario-specific Lua scripts.
Plan specifies the plan file.
Overlay specifies the overlay file.
SelectionGroups specifies the selection groups file.
Object-Map specifies the object mapping file.
Scenario-Extras specifies the extras file, which records force hostility relationships, and stores spawn pattern templates. It may be used for other purposes in the future.
time-multiplier specifies whether a scenario runs in real time or faster than real time. A value greater than 1 runs the simulation faster than real time. You can set this value dynamically using the Time Multiplier toolbar.
!
!
If you are running a scenario using HLA Time Management, it is strongly recommended that you set time-multiplier to 1.
auto-reorganize lets you specify the default behavior for unit reorganization. Set it to True or False. For information about reorganization, please see “How Units Are Organized,” on page 22-3.
random-number-seed sets the default random number seed. It provides a starting point for the generation of random numbers needed by VR-Forces. Enter an integer between 0 and the largest integer permitted on your system.
frame-mode sets the frame rate mode to one of the following:
Variable-Frame Run-To-Complete (variable-frame)
Fixed-Frame Best-Effort (fixed-frame)
Fixed-Frame Run-To-Complete (fixed-frame-run-to-complete). These frame rate modes are described in “Exercise Clock Modes,” on page 3-11.
frame-time specifies the length of a frame, in seconds. If frame-mode is set to fixed-
frame or fixed-frame-run-to-complete, you must set the frame time to a non-zero value. A value of zero for frame time will prevent simulation time from advancing in either of these modes.
run-duration-time specifies how long the scenario should run before automatically stopping.
additional-opds specifies custom OPD files to load (for backwards compatibility).
Simulation-Model-Set-Files specifies a list of SMS files to load.
scenario-name is an optional parameter that assigns a name to the scenario. It is inde- pendent of the file name and is only used in some message dialog boxes.
scenario-data is the name of a block of data with the following additional parame- ters:
Create_Global_Dynamic_Terrain specifies whether or not the global dynamic terrain processor should be enabled. If this is disabled, dynamic terrain does not work unless you create a dynamic terrain area.
Create_Global_Environment specifies whether or not the scenario supports environ- mental conditions.
DefaultObserverView specifies the observer view to use at startup.
GuiObserverViews specifies the saved views file for the scenario.
GuiScenarioSettings specifies the .gui_settings file. It records scenario-specific GUI settings.
ScenarioDescription is the text of the scenario description.
ScenarioExtentInformation lists the extents of the scenario for the zoom to extents option.
Set_Scenario_Start_Time_At_Local_On_First_Object_Creation specifies the start time for the scenario, in seconds.
UseDayNightModel specifies whether or not to use the day/night illumination model.
version specifies versioning information for the scenario file. Do not edit this parameter.
The sim-time and exercise-start-time parameters are in the scenario file for backwards compatibility. They are not supported in scenarios created after VR-Forces 4.0.3.
Pathnames in a scenario file can be absolute or relative. When VR-Forces saves a new scenario, it creates pathnames that are relative to the application directory. If you think you might need to move a scenario to another computer or a new directory structure, change the paths to be relative to the ./bin64 directory. To change pathnames, edit the scenario file in a text editor. VR-Forces preserves the new paths when it saves the scenario.
!
!
If you plan to run multiple front-ends and back-ends on multiple machines, particularly if they use different operating systems, you must change the pathnames for the terrain database and object parameter database to relative paths or simple pathnames.
The following parameters in vrfSim.mtl determine how pathnames for the object parameter database and terrain database are resolved:
defaultParameterDatabasePath specifies the path to search for OPD files when an explicit path is not specified in a scenario file.
defaultTerrainDatabasePath specifies the path to search for terrain database files when an explicit path is not specified in a scenario file.
When the back-end loads a scenario file, it looks for the object parameter database using the following search order:
If the path is absolute, load the file in the specified path.
If the path is relative, try to load the file relative to the application path (./bin64/vrfSimprotocol).
Look in the directory specified by defaultParameterDatabasePath.
When the back-end loads a scenario file, it looks for the terrain database using the following search order:
If the path is absolute, load the file in the specified path.
If the path is relative, try to load the file relative to the application path.
Look in the directory specified by defaultTerrainDatabasePath.
Use the path in the user-defined environmental variable VRF_TERRAIN_PATH, if it is specified.
Scenario Files — The Plan File
When you create a new scenario, you must choose terrain databases for the front-end and back-end. By default, the back-end uses the same database as the front end.
Once you have chosen the terrain database, you cannot change it from the graphical user interface. You can edit the pathname of a terrain database in the scenario file. However, unless the new terrain database covers exactly the same geographic area as the old one, the order of battle and overlay information associated with the scenario may be confusing or useless.
VR-Forces saves all individual and global plans to a plan file (.pln).
Plan files are created interactively in the VR-Forces Plan window. The Plan window ensures that the plan is written using the correct syntax. We recommend that you not try to create plan files or edit plan files by hand.
Scenario Files — The Object Map File
When you start VR-Forces with multiple back-ends, you can specify which back-ends simulate the various objects you create. The object map file records the back-ends on which objects are simulated. The next time you open the scenario, VR-Forces looks for the back-ends specified in the object map file. If any of the specified back-ends is not available, the front-end asks you if you want to remap objects to the back-ends that are present. You can run the simulation without remapping. However, the behavior of a simulation that is missing simulation objects is unpredictable.
(map-entry
(address 1 3201)
(name "M1A2 1")
)
(map-entry
(address 2 3400)
(name "T80 2")
)
(map-entry
(address 1 3201) (name "route_1")
)
The address parameter lists the site and application number used for the back-end on which the object was simulated.
If you want to run an existing scenario using back-ends with different site and applica- tion values, you could edit the object map file and change the address field to match the new site and application values. However, if you make any mistakes in this process, your scenario might not run correctly. As an alternative to editing the object map file by hand, you could use the load balancing option to remap objects to back ends. For details about load balancing, please see “Load Balancing a Scenario,” on page 7-19.
Scenario Files — Editing the Order of Battle File
When a simulation object in a scenario is saved to the OOB file, parameters that are unchanged from the initial values in the object parameter database entry are written out in the form:
(parameter-name USE-DEFAULT)
The USE-DEFAULT keyword indicates that the next time this file is loaded (as part of a scenario) it should be initialized from data in the simulation object’s OPD entry. The practical effect of the USE-DEFAULT keyword in OOB files is that if you modify the object parameter database, the next time you load a scenario those changes can affect the simulation objects in the scenario.
This lets you experiment with changes to parameters and view the effects of the changes to existing scenarios, without modifying the order of battle files.
VR-Forces lets you configure hostility relationships. That is, for any force you can specify which forces it is hostile to. By default Friendly and Opposing forces are hostile to each other. If you change the hostility relationships, they are saved in the scenario extras file (.xtr).
This file also stores spawn patterns.
Scenario Files — Temporary Scenario Directories
When you load a scenario, VR-Forces creates temporary directories in which it stores files that it needs to maintain and update the scenario. To prevent conflicts in the temporary directories when running multiple copies of VR-Forces from the same direc- tory, VR-Forces creates unique temporary directories. The directories are created in the path specified by the TMP environment variable. If this variable is not specified on Linux, the /tmp directory is used. The TMP variable must be specified on Windows. If VR-Forces cannot create a temporary directory, an error message is printed and the application exits. In the front-end, the temporary directory is created by DtVrfRemote- Controller and starts with the prefix vrffe. In the back-end, the temporary directory is created by DtCgfDispatcher and has the prefix vrfbe. In both cases, the temporary direc- tory is removed when VR-Forces shuts down.
Scenario Files — Temporary Scenario Directories
13. Using a Communica- tions Effects Server
This chapter explains how to configure VR-Forces to interoperate with an external communications effects server.
Enabling the External Communication Model 13-3
Configuring the External Communication Model 13-3
Using a Communications Effects Server — Introduction
Communication models determine how radio messages travel from one simulation object to another. They determine which simulation objects are connected to each other and how long it takes a message to get from one to another.
You can configure VR-Forces to use an external communications effects server to control the transmission of radio messages between VR-Forces simulation objects. The communications effects server determines which simulation objects are able to commu- nicate with each other, and how long it takes a message to be transmitted from the orig- inator of the message to the receiver of the message.
Communication model classes are derived from DtCommModel and are generated from the communication model factory based on the string types specified in the commMod- elParams.mtl file. A communication model entry contains parameters for the type of communication model descriptor and communication model class being used.
VR-Forces supports the interface specified in the file ./doc/QualNet_HLA_inter- face_RPR-FOM 1.0_extensions_ICD3.pdf. This Interface Control Document (ICD) was created by Scalable Network Technologies and is distributed with their permission. Any communications effects server that conforms to this interface can be used with VR-Forces.
Enable the publishing of radio transmitters for any entity types that will be sending messages through the communications effects server. For details, please see “Publishing Radio Transmitters,” on page 74-4.
Set the external communication model as the communication model to be used by VR-Forces.
Configure the external communication model.
Using a Communications Effects Server — Configuring VR-Forces
You can enable external communication in the front-end or by editing ./data/simula- tionModelSets/<model_set>/commModelParams.mtl. When you enable the external communication model in the front-end, VR-Forces also enables publishing of transmit- ters on all simulation objects that have radios. When you change the communication model setting, it gets saved. The next time you run VR-Forces, the saved setting is used.
!
!
When you change the communication model setting, existing transmitters are destroyed and new transmitters are created.
To enable or disable the external communication model, choose Settings Use External Communication Model.
To enable the External Communication Model, edit ./data/simulationModel- Sets/<model_set>/commModelParams.mtl. This file defines the communication models available to the scenarios. By default, VR-Forces is configured to use the simple-radio- comm-model, which allows all communication between simulation objects to be received.
To use an external server for all radio communication, comment out the simple- radio-comm-model block, and uncomment the external-comm-model block.
This causes the external server to be used for all radio communication.
If you enable the external communication model, you can set the following configura- tion options in commModelParams.mtl:
use-actual-message-size specifies how the size of the messages will be modeled. When a message is sent using the external communication model, a message size is sent to the external communications effects server, and that number may affect how long it takes for the message to reach its recipient. If this parameter is set to True (the default), the actual number of bytes of the VR-Forces message is used for this size value. This includes the VR-Forces message header of the sender or recipient and the contents of the message. If this parameter is set to False, the size specified by substitute-message-size is used for all messages.
substitute-message-size specifies the message size, in bytes, to send to the external communications effects server. It is used only if use-actual-message-size is False.
message-timeout specifies the timeout value, in seconds, for messages sent to the communications effects server. Messages that are not delivered to the server by the end of the timeout period are dropped.
Using a Communications Effects Server — Configuring VR-Forces
14. Example Entity-Level Scenarios
VR-Forces includes several sample scenarios. This chapter explains how to create the breaching scenario and the embarkexample scenario. It assumes some basic knowledge of VR-Forces concepts and the VR-Forces interface, such as how to select objects, how to pan and zoom the terrain, and so on. If you have not yet reviewed the entity-level sample tutorial in VR-Forces First Experience, you may want to try that tutorial before trying these example scenarios. VR-Forces First Experience also contains an aggregate- level scenario tutorial.
Create the Opposing Forces 14-5
Create the Tactical Graphics 14-7
Create the Friendly Simulation Objects 14-9
The Embarkexample Scenario 14-22
Create the Simulation Objects 14-23
Create the Tactical Graphics 14-26
Write the Plans for the Entities 14-28
This scenario simulates a breaching exercise. In this exercise, four hostile vehicles are arrayed behind a minefield. Three platoons of four tanks each suppress the hostile vehi- cles, allowing two engineering vehicles to clear the minefield. This scenario uses Enti- tyLevel.sms.
Figure 14-1 illustrates the order of battle and tactical graphics in the scenario.
Red Force
Minefield Waypoint Bravo Breach route Waypoint Alpha 3rd Platoon 2nd Platoon
1st Platoon Engineering units
Figure 14-1. Breaching scenario order of battle
The scenario demonstrates the following features of VR-Forces:
Creating simulation objects.
Creating tactical graphics (waypoints, routes, areas).
Creating a predefined unit and creating a unit from individual entities.
Creating plans, using:
Move To.
Follow Entity.
Follow Route.
Conditions.
The scenario plays out as follows for the Blue force simulation objects:
3rd Platoon stays in position and fires on hostile forces.
1st Platoon advances to waypoint Alpha and provides cover for the engineers.
2nd Platoon advances to waypoint Bravo and provides cover for the engineers.
When the hostile forces are destroyed, the engineering entities advance on the minefield to clear it.
The scenario has entities that represent engineering entities, but
EntityLevel.sms does not actually have models for engineering entities.
You can view videos that demonstrate this tutorial at ./doc/vrforces_tutorialvideos.htm, or click the camera icon next to the procedure whose video you want to view.
To create the scenario:
Start VR-Forces. The VR-Forces window opens and the Scenario Startup dialog box opens on top of it.
Select the New Scenatio option.
In the Terrain list, select SanLuisObispo.
Click OK. The San Luis Obispo database is displayed. This database covers a portion of California, U.S.A.
Save the scenario periodically as you work on it.
To save the scenario:
Choose File Save Scenario. The Save Scenario dialog box opens. By default, the name you gave to the scenario when you created it is automatically entered.
Click the New Folder button. A new folder is added to the window.
Type a name for the new folder, such as myBreaching.
Select the folder.
Click Open.
In the File Name box, type a name for the scenario, such as myBreaching.
Click Save.
We will create the minefield first, since it becomes a good reference around which to create the simulation objects and other objects.
To create the minefield:
Zoom in on a relatively flat portion of the terrain. This is to minimize the impact of hilly terrain and intervisibility issues on how the simulation runs. For this scenario, we used an area just to the northeast of the center of the terrain (Figure 14-2).
Click the Tactical Graphics tab on the right side of the window. The Tactical Graphics Palette opens.
In the Categories list, select Engineering.
In the list of tactical graphics, select Minefield. The Create Minefield tab gets added to the window and the cursor changes to a a minefield icon.
Click the Create Minefield tab. The Create Minefield dialog box opens (Figure 14-3).
In the Name box, type Minefield.
Draw an oblong area to define a minefield (Figure 14-3). Click to define the first three vertices. Right-click to define the last vertex.
Figure 14-3. Create the minefield
Now that we have the minefield as a reference point, we can create the hostile entities.
To create the opposing forces:
Click the Simulation Objects Palette (on the right margin of the window).
In the Category list, select Ground.
In the Force list, select Opposing.
In the list of entities, select T-80 MBT.
Click on the map north of the minefield four times, as indicated in Figure 14-1, to place the T-80s.
Right-click to exit create mode.
We will want to test for when all of the opposing forces are destroyed. This will be easier to do if they are in a unit.
To aggregate the opposing forces:
Select the four T-80 tanks.
Choose Objects Aggregate As. The Aggregate As dialog box opens (Figure 14-4).
In the list, select Ground Unit.
Click OK. The tanks are aggregated into a platoon.
In the Echelon View tab on the Objects List Panel, expand the unit (Figure 14-5).
Select the unit (Gnd 1, not individual members).
Choose Objects Edit. The Edit Armor Plt (CIS) dialog box opens.
In the name text box, replace the default name with 1st Platoon.
Click Update.
Save the scenario.
We need to create two waypoints and a route for the Blue Force.
To create the waypoints:
Click the Tactical Graphics Palette (on the right margin of the window).
In the Category list, select Control Objects.
In the list of control objects, select Waypoint. The Create Waypoint tab is added to the window.
Click the Create Waypoint tab. The Create Waypoint dialog box opens.
Type a name for the waypoint, such as Alpha.
Using Figure 14-1 as a guide, click on the map where you want to place the waypoint.
In the Create Waypoint dialog box, type a name for the second waypoint, such as Bravo.
Click on the terrain where you want to place the waypoint.
Right-click to exit draw mode.
To create the route:
Click the Tactical Graphics Palette.
In the list of control objects, select Route. The Create Route tab is added to the window.
Click the Create Route tab. The Create Route dialog box opens.
Type a name for the route, such as “Breach route”.
Click on a point just east of waypoint Alpha.
Move the mouse cursor to the edge of the minefield.
Right-click to place the end point in the route.
Save the scenario.
At this point, the scenario should look something like Figure 14-6.
Figure 14-6. Breaching scenario progress
Using Figure 14-1 as a guide to location, create the friendly simulation objects. We will create one platoon from individual entities, and the other two using preconfigured platoons.
To create the friendly simulation objects:
Click the Simulation Objects Palette.
In the Categories list, select Unit.
In the Force list, select Friendly.
In the list of entities displayed, select Armor Plt (US).
Click on the map to place 1st Platoon and 2nd Platoon as shown in Figure 14-1. Right-click to exit create mode. The units are created with default names (ARPlt 1 and ARPlt 2). They are disaggregated and expanded, so you can see the individual entities.
Choose Objects Edit. The Edit Armor Plt (US) dialog box opens.
In the name text box, replace the default name with 1st Platoon or 2nd Platoon, depending on which platoon you selected. (You already have an opposing force platoon named 1st Platoon. However, you can have multiple simulation objects with the same name. VR-Forces assigns each simulation object a unique ID to ensure there is no confusion in the simulation engine.)
Click Update.
Rename the other platoon that you created.
Click the Simulation Objects Palette.
In the Categories list, select Ground.
In the list of simulation objects, click M1A2 Abrams MBT. The cursor changes to draw mode.
Click on the map where 3rd Platoon should be. A simulation object icon is displayed.
Click three more times to create the rest of the tanks in 3rd Platoon. Right-click to exit create mode. (We will create the unit from these simulation objects in the next section.)
Open the Simulation Objects Palette.
In the Ground/Friendly category, select M58 MICLIC.
Click twice on the map to the south of 1st Platoon to create two MICLIC entities.
Right-click to exit create mode.
Save the scenario.
To create 3rd Platoon:
Select the four members of 3rd Platoon.
Choose Objects Aggregates As. The Aggregate As dialog box opens.
Select Ground Unit from the list.
Click OK.
Select the new platoon.
Choose Objects Edit. The Edit Scene Object dialog box opens.
Change the name to 3rd Platoon.
Save the scenario.
The plans tell the simulation objects how to carry out their roles in the scenario. 3rd Platoon just stays in place. We do not give it a plan. It will just respond to any opposing force entities that it detects.
2nd Platoon will move to a waypoint. As it moves it responds to any opposing force entities that it detects. The plan is quite simple to write.
To write the plan for 2nd Platoon:
Select 2nd Platoon.
Choose Objects Plan. The Plan window opens (Figure 14-8).
In the Plan window, choose Task Movement Move to Waypoint. The Move to Waypoint dialog box opens (Figure 14-9).
In the Move to Waypoint dialog box, or on the map, select Bravo.
Click OK. The task is added to the plan. The plan is now complete (Figure 14-10).
In the Plan window, click OK.
1st Platoon moves to waypoint Alpha. It has another job to do. When all the opposing forces are destroyed, it sends a message on the radio network. The MICLICs are listening for the message. They will not try to clear the minefield until they receive it.
To write the plan for 1st Platoon:
Select 1st Platoon.
Press p. The Plan window opens.
In the Plan window, choose Task Movement Move to Waypoint. The Move to Waypoint dialog box opens (Figure 14-9).
In the Move to Waypoint dialog box, or on the map, select waypoint Alpha.
Click OK. The task is added to the plan (Figure 14-11).
Select the top line in the plan (the text Plan).
In the Plan window, choose Conditions Add Trigger. The Edit Trigger Condition dialog box opens (Figure 14-12).
In the Trigger Name box, type Red Force Platoon Destroyed.
In the list box with the text <choose a conditional>, select Entity Destroyed. The Entity Destroyed dialog box opens.
In the list of simulation objects, select 1st Platoon (opposing force) (Figure 14-13).
Click OK. The expression is added to the dialog box in the bottom pane (Figure 14-14).
In the Edit Trigger Condition dialog box, click OK. The Plan window expands to let you build the trigger body (Figure 14-15). Now we need to add tasks to execute when the trigger becomes true.
The line labeled Trigger Body should be selected. If not, select it.
Choose Task Radio Send Text Message. The Send Text dialog box opens.
In the list, select SmWhel 1.
In the Message Text box, type Opposing Force Destroyed (Figure 14-16).
Click OK. The trigger body is now finished.
In the left pane of the Plan Window, select the top line (with the text Plan) (Figure 14-17).
Choose Conditions Register Trigger. The Register Trigger dialog box opens (Figure 14-18). The trigger you created is listed in the Trigger list.
Click OK. The Trigger is registered in the plan.
The plan for 1st Platoon is finished (Figure 14-19).
Click OK.
Save the scenario.
When the MICLICs are notified that the opposing force has been destroyed, they move along a route to the edge of the minefield. Then they clear it.
The MICLICs provided with VR-Forces do not actually have the ability to simulate clearing a minefield. We are going to provide some visual interest by using global commands to remove the original minefield and replace it with two minefields with a space between them.
We will start with the plan for SmWhel 1:
Select SmWhel 1.
Press p. The Plan window opens.
In the Plan window, choose Conditions Add Trigger. The Edit Trigger Condition dialog box opens.
In the conditions list, select Receive Text Message. The Receive Text Message dialog box opens.
Type the message that we are waiting for (Opposing Force Destroyed) (Figure 14-20).
Click OK.
In the Edit Trigger Condition dialog box, click OK. The trigger condition is added to the plan window (Figure 14-21). Now we need to tell the entity what to do when it gets this message (move along the route, then redraw the minefield).
In the Trigger Body pane, make sure that Trigger Body is selected.
Choose Task Movement Move Along Route. The Move Along Route dialog box opens.
Select Breach route, then click OK. The task is added to the trigger body.
As we said earlier, EntityLevel.sms does not actually model minefields or the types of simulation objects that could clear one. To provide the visual illusion of clearing a corridor through the minefield, after the MICLICs arrive at the end of the route, we will delete the minefield and create two new minefields that occupy most of the space of the original one, but leaves a corridor for entities to travel through.
Choose Commands Delete. The Delete dialog box opens.
In the list, select Minefield.
Click OK.
Choose Commands Create Tactical Graphics. The Tactical Graphics dialog box opens. It mimics the Tactical Graphics palette.
Select Minefield. The Create Minefield dialog box opens.
Type Minefield-left in the Name box.
Draw an area over most of the minefield to the left of where the breach route inter- sects the minefield. (You might need to drag the Plan window out of the way. If the Create Minefield dialog box is in the way, click the Create Minefield tab to mini- mize it.
Right-click to complete the minefield. The Create Minefield dialog box closes. You will not see this new area, because it does not exist in the simulation yet. It will not exist until the command gets executed.
Repeat steps 14 through 18, but this time draw the minefield to the right of the route. Call it Minefield-right. The trigger body should now be similar to Figure 14-22.
In the left pane, select the line labeled Plan.
Choose Conditions Register Trigger. The Register Trigger dialog box opens. The trigger you created is listed in the Trigger list.
Click OK. The plan is now complete (Figure 14-23).
Save the scenario.
Figure 14-24. Plan for SmWhel 2
Be sure to save the scenario before you run the simulation. If you want to save it in its starting state, do not save it after you run the simulation.
Once you have created the scenario and saved it, click the Run button and watch the simulation run. Open the plan windows for the MICLICs and observe the progression of tasks through the plan.
If hostile entities do not get destroyed, it may be that the blue entities cannot see them. If they cannot see them, they cannot shoot each other. Use the intervisibility feature to test line-of-sight. Move the entities around, or find a flatter section of the terrain until you get the results you want.
You can run the breaching scenario included with VR-Forces and see how it compares to the one that you created.
Figure 14-25 shows the breaching scenario after the MICLICs have completed their plans. All of the aggregates are expanded so that you can see the individual entities.
Figure 14-25. Breaching scenario after minefield cleared
The embarkexample scenario (Figure 14-26) demonstrates the embarkation feature. It shows the following:
Embarking and disembarking entities using embarkation tasks.
Embarking an entity using automatic embarkation.
The scenario also demonstrates various types of conditional statements including nested triggers, radio text messages, radio task messages, and a global plan.
A completed scenario is included with VR-Forces in ./userData/scenarios/embarkex- ample. This section is a step-by-step explanation of how to create the scenario. It assumes that you have completed the breaching scenario example and does not provide quite as much detail for how to create simulation objects and tactical graphics. This scenario uses EntityLevel.sms.
If you are using HLA, you must use RPR FOM 2 draft 17 or later for scenarios that use embarkation.
Landing area
M2A2 R 1
Figure 14-26. Embarkexample scenario
The scenario has the following simulation objects (marking text in Figure 14-26):
An F/A-18 Hornet fixed-wing aircraft (FtrFW 1).
A helicopter (UtilRW 1, not visible) embarked on an LSD-49 Harpers Ferry ship (Harper 1).
A DI (R 1) standing behind a Bradley vehicle (M2A2 1) in the town.
An aircraft carrier (Carrier 1).
The scenario has the following tactical graphics:
A waypoint for the Bradley vehicle to drive to.
A waypoint for the helicopter to land at.
A waypoint on the carrier deck for the DI to walk to.
To create the entities:
Start VR-Forces.
Choose File New Scenario. The Initial Scenario Information dialog box opens.
Select AlaMoana.mtf.
Click Open. The New Scenario dialog box opens.
Click OK. The Ala Moana database is displayed.
Navigate to Honolulu, Hawaii. (You can move here quickly if you load the AlaMo- andInset.osrx saved views file. For information about loading saved views, please see “Saving and Recalling Views,” on page 49-30.)
Using the Simulation Objects Palette, create the following entities in the locations shown in Figure 14-26:
Harpers Ferry-class LSD.
Nimitz class-Carrier.
F/A-18 Hornet.
M2A2 Bradley IFV (Figure 14-27 shows a closeup view of the location of the Mm2A2 Bradley and the US Army M16.)
US Army M16.
We will create the helicopter in a separate procedure that demonstrates automatic embarkation.
Set the altitude of the F/A-18 to 1000 meters.
Save the scenario.
We will add the helicopter using automatic embarkation.
To add the helicopter:
Set the display to Stealth observer mode.
In the Objects List Panel, right-click Harper 1 and choose Observer Attach
Attach Follow. The observer attaches to the Harpers Ferry LSD ship.
Press the right arrow key a few times to get a broadside view of the ship.
On the Simulation Objects Palette, in the Rotary Wing category, select CH-46E Sea Knight. The cursor changes to create mode.
Move the cursor over the Harpers Ferry LSD ship. A green selection box is displayed (Figure 14-28).
Click the left mouse button. A CH46E Sea Knight helicopter is created and embarked onto the Harpers Ferry LSD.
Right-click to exit create mode.
We need a few tactical graphics to specify the movement tasks for the entities. The Bradley vehicle will drive across town to a landing area. The helicopter will land there and pick up the DI.
To create the waypoints at the landing area:
Set the observer to Plan View observer mode.
Zoom in on the landing area, outlined in Figure 14-26 and shown more closely in Figure 14-29.
Put a waypoint along the road for the Bradley to drive to.
Put a waypoint in the middle of the grassy area for the helicopter to land at.
Figure 14-29. Waypoints at landing area
We want to attach a waypoint to the carrier. However, in the 2D view, there is no way to figure out where to place the waypoint because the carrier is shown as a 2D icon. So, we will switch to the 3D view.
To attach a waypoint to the carrier:
Change to Stealth observer mode.
Attach the observer to the aircraft carrier.
Zoom in a bit so you have a good view of the carrier deck and control tower.
Choose Create Waypoint.
Click on the deck of the carrier next to the control tower (Figure 14-30).
Right-click.
Save the scenario.
We need to write plans for the entities to do the following:
The jet will embark on the carrier (land and taxi to a parking place). When instructed to do so by the DI, it will disembark (take off).
The DI will embark on the Bradley and ride with it to the landing area. It will then disembark from the Bradley and embark on the helicopter. When the helicopter gets to the carrier, the DI will disembark and walk to the waypoint. It will then tell the helicopter and the jet to disembark.
The helicopter will disembark from the Harpers Ferry LSD and fly to the landing area, where it will land. The DIs will embark on it. Then it will take off and embark on the carrier. When instructed to do so by the DI, it disembarks from the carrier and embarks on the Harpers Ferry LSD.
As you can see, the entities do a lot of embarking and disembarking. They will use radio messages to coordinate their activities.
At the start of the scenario, the jet is in the air executing its default behavior, which is to loiter. Its plan will tell it to embark on the carrier. To accomplish this, it creates a route to line it up with the carrier deck, lands on the deck, and taxis to a parking slot.
However, you do not have to figure any of this out. You just have to tell it to embark.
A trigger condition triggers when the jet receives a message from the DI. It disembarks and flies to 5000 meters.
To write the fixed-wing aircraft’s plan:
Select the fixed-wing entity.
Choose Objects Plan. The Plan window opens.
Choose Task Embarkation Embark. The Embark On dialog box opens.
In the Embark On dialog box, select Carrier 1 from the list and click OK.
Choose Conditions Add Trigger. The Edit Trigger Condition dialog box opens.
In the list that says <choose a conditional>, select Receive Text Message.
In the Receive Text Message dialog box, type the message text Start patrol..
Click OK.
In the Edit Trigger Condition dialog box, click OK. The Plan window expands to show the Trigger Body pane and lists the new trigger in the Triggers list.
Choose Task Embarkation Disembark.
Choose Task Movement Fly Altitude. The Fly Altitude dialog box opens. (When the jet disembarks, it loiters at about 175 meters. We want to get it quite a bit higher.)
Specify an altitude of 5000 meters.
Specify a climb rate of 1000 meters/minute.
In the Fly Altitude dialog box, click OK.
In the Plan window, select the Embark Entity task (Line 1).
Choose Conditions Register Trigger. The Register Trigger dialog box opens. There is only one trigger in the list.
Click OK. The plan for the fixed-wing entity is finished (Figure 14-31).
The helicopter needs to disembark from the Harpers Ferry LSD, fly to the landing area, pick up the DI, and fly to the carrier. We will have it wait on the ship until the DI is embarked on the Bradley, so that the timing works out.
To write the helicopter’s plan:
On the Objects List Panel, Entity List view, select the helicopter entity. (Since the helicopter is embarked, it is not visible on the map in Plan View mode, so you cannot select it there. If you are in the 3D view, you can select the copter in the Objects List Panel or by clicking the model.)
Choose Objects Plan. The Plan window opens.
Choose Conditions Add Trigger. The Edit Trigger Condition dialog box opens.
For the condition, select Entity Embarked. The Entity Embarked dialog box opens.
On the Name tab, in the top list, select R 1. This is the entity whose embarkation status we want the helicopter to monitor.
In the bottom list, select M2A2 1. We want to test the condition that R 1 is embarked on M2A2 1.
In the Entity Embarked dialog box, click OK.
In the Edit Trigger Condition dialog box, click OK. The trigger is displayed in the Trigger Body pane of the plan. Now we need to specify what the helicopter should do when the condition is true.
In the Trigger Body pane, select the top line (Trigger Body).
Choose Task Embarkation Disembark.
Choose Task Movement Rotary Wing Land. The Rotary Wing Land dialog box opens.
In the list of waypoints, select Waypoint 2 and click OK.
When the helicopter lands, it sends a message to the DIs to tell them that it is OK to embark.
Choose Task Radio Send Text Message. The Send Text dialog box opens.
Select R 1. This will direct the message just to this entity.
In the Message Text box, type All aboard..
Click OK. The plan looks like Figure 14-32. When the helicopter lands, it will tell DI 1 to load up, so that it knows it is time to embark on the helicopter.
After the helicopter lands, it needs to wait until the DI has embarked before it takes off. So we use a trigger with an Entity Embarked condition. The helicopter does not need to watch for this entity to be embarked until it lands, so we can put the trigger statement in the middle of the plan rather than at the beginning as we might with other conditions.
Figure 14-32. R 1 embarked on M2A2 1 trigger
In the Plan window, select the first line (Plan).
Choose Conditions Register Trigger. The Register Trigger dialog box opens.
Select “R 1” embarked on “M2A2 1”.
Click OK.
Choose Conditions Add Trigger.
For the condition, select Entity Embarked. The Entity Embarked dialog box opens.
On the Name tab, in the top list, select R 1.
In the bottom list, select UtilRW1.
In the Entity Embarked dialog box, click OK. Then, click OK in the Edit Trigger Condition dialog box.
In the Trigger Body pane, select the top line.
Choose Task Embark.
Specify that the helicopter embark on Carrier 1.
Click OK.
In the Plan window, select Line 1.
Choose Conditions Register Trigger. The Register Trigger dialog box opens.
Select “R 1” embarked on “UtilRW 1”.
Figure 14-33. Rotary-wing plan
The Bradley waits until R 1 embarks on it, then drives to the landing area. It tells R 1 to get out. In the previous sections, you have learned how to create triggers and register them, so this procedure will abbreviate the steps.
To write the plan for the Bradley vehicle:
Select the Bradley.
Choose Objects Plan, or press p. The Plan window opens.
Choose Conditions Add Trigger. The Edit Trigger Condition dialog box opens.
For the condition, select Entity Embarked. The Entity Embarked dialog box opens.
On the Name tab, in the top list, select R 1.
In the bottom list, select M2A2 1.
In the Entity Embarked dialog box, click OK.
Click OK in the Edit Trigger Condition dialog box.
In the Trigger Body, add a Move to Waypoint (Plan Along Roads) task for the Bradley to move to Waypoint 1.
Add a Send Text Message task to send the text Disembark now. to R 1.
Register the trigger.
Save the plan (Figure 14-34).
The DI embarks on the Bradley and rides to the landing area. It gets on the helicopter and flies to the carrier, where it disembarks and walks to the waypoint on the carrier deck. Then it tells the helicopter and jet to disembark.
The DI’s plan has three triggers, one of which is nested in another. To make it easier to refer to them we will give them names instead of using the default names. The triggers are:
Disembark from M2A2 sets up the response of the DI when the Bradley reaches the landing area and tells it to disembark.
Embark on Copter has the tasks for the entity when it is told to embark on the heli- copter.
Disembark from Copter tells the DI what to do when the helicopter returns to the carrier.
The organization of conditional statements in a plan is important. (For discussion, please see “Considerations for Using Triggers,” on page 35-17.) We want to be sure that the conditions in the plan get registered, so normally we put them at the top of the plan. However, we do not want some tasks to be carried out until the DI is embarked on the helicopter and the helicopter is embarked on the carrier, so we nest Disembark from Copter inside Embark on Copter.
To write the plan for the DI:
Select the DI.
Choose Objects Plan. The Plan window opens.
Add the Disembark from M2A2 trigger:
Choose Conditions Add Trigger.
Select the condition Receive Text Message.
In the Receive Text Message dialog box, type the message text Disembark now.. This matches the text you put in the Send Text Message task for the Bradley vehicle.
Click OK to back out of the dialog boxes.
In the Trigger Body, add a Disembark task.
The plan should look like Figure 14-35.
Create the Embark on Copter trigger:
Add a new trigger.
For the condition in this trigger, select Receive Text Message.
In the Receive Text Message dialog box, type the message text All aboard.. This matches the text you put in the Send Text Message task for the helicopter.
Click OK to back out of the dialog boxes.
In the Trigger Body, set the speed to 10.0 km/h. This is fast enough so that the DI will run to the helicopter instead of walking. The plan should now look like Figure 14-36. This trigger is not quite finished, because we need to embed a trigger in it. However, first we must create that trigger.
Figure 14-36. Embark on Copter trigger (incomplete)
Create the Disembark from Copter trigger:
For the condition in this trigger, select the Entity Embarked condition and specify the helicopter (UtilRW 1) embarked on the carrier (Carrier 1). This condition will trigger when the helicopter flies to the carrier and lands on the deck.
Click OK to back out of the dialog boxes.
In the Trigger Body, add a Wait Duration, 30 seconds task. This task means that when the helicopter embarks on the carrier, the DI entity waits 30 seconds before it disembarks. (This is a timing issue. The simulation engine usually considers the helicopter to be embarked before it has finished the visualization of the landing process. If you do not put in a Wait here, the DI will disembark as soon as the simulation engine thinks the helicopter is embarked. This could put it in the ocean or under the carrier deck.)
Add a Disembark task. This disembarks the DI from the helicopter. Since the helicopter is embarked on the carrier, the DI is automatically embarked on the carrier.
Add a Move to Waypoint task to Waypoint 3. After the DI disembarks from the helicopter, it walks across the deck to the waypoint.
Send a task message to UtilRW 1 to embark on Harper 1. It will disembark from the carrier, fly to the Harpers Ferry LSD, and embark on it.
Send a text message to FtrFW 1 to Start patrol.. The plan should look like Figure 14-37.
In the Triggers list, select Embark on Copter. The contents of the trigger is displayed.
Select the second statement in the trigger.
Register the trigger Disembark from Copter. The plan should look like (Figure 14-38)
Figure 14-38. Embark on Copter trigger with nested trigger
Now we will put everything together to create the plan.
In the main list of plan tasks, select Plan.
Register the trigger Disembark from M2A2.
Task this entity to embark on the Bradley vehicle. This task will actually be the first thing the DI does when the scenario starts. The plan should look like (Figure
14-39).
Register the trigger Embark on Copter. The completed plan should look like (Figure 14-39).
Figure 14-40. RW 1 plan
Click OK.
Save the scenario.
Run the scenario.
The chapters in this section explain how to add simulation objects to a scenario, how to select them, and how to display information about them.
VR-Forces Users Guide
Section III - Simulation Objects
III-1
Section III - Simulation Objects
III-2 VT MAK
15. Introduction to Simula- tion Objects
Simulation objects are the entities and units that VR-Forces simulates as part of a scenario.
How Simulation Objects are Identified 15-3
How Simulation Objects are Organized 15-6
How Echelon IDs are Assigned 15-7
How Simulation Objects Communicate 15-7
External Communication Model 15-7
Custom Communication Models 15-8
VR-Forces Uses a Component Architecture 15-8
Simulation Object Behaviors and Tasks 15-10
Entity-Level Modeling and Aggregate-Level Modeling 15-10
Introduction to Simulation Objects — Simulation Objects
Entities, which represent a discrete individual vehicle or person, such as a tank or a submarine.
Units, which represent a hierarchical group of entities, units, or both, such as a platoon or a company.
The concepts described in this section are generally applicable to entity-level modeling and aggregate-level modeling. For details about the differences between aggregate-level modeling and entity-level modeling, please see “Entity-Level Modeling and Aggregate- Level Modeling,” on page 15-10.
Simulation objects can act in and respond to their environment. They execute tasks and they have behaviors. Each simulation object is part of a force and may be a member of an organizational unit.
VR-Forces identifies simulation objects by UUID (universal unique ID), name, echelon ID, object ID, and label. Table 15-1 summarizes the characteristics of each type of identifier.
Table 15-1: Simulation object identifiers
Identifier Characteristics
Identifier Characteristics
UUID Unique. Assigned by VR-Forces.
Persists from exercise to exercise.
Name Persists from exercise to exercise.
Set by user.
Limits on the length of the character string.
Does not have to be unique.
Echelon ID Must be unique.
Persists from exercise to exercise.
Assigned by VR-Forces. Changes if an entity is organized into a unit.
Object ID Unique.
Does not persist from exercise to exercise.
No user control.
Label Does not have to be unique.
Persists from exercise to exercise.
Controlled by user.
No limit on character length.
UUIDs are unique identifiers generated by VR-Forces to ensure that every simulation object can be uniquely identified and that the identification persists each time you run the scenario. In particular, the use of UUIDs supports importation of scenarios because while simulation objects in different scenarios might have the same names, they will not have the same UUIDs, so it is possible to import them and not change their names if you do not want to. (The default is to rename duplicate simulation objects.)
Introduction to Simulation Objects — How Simulation Objects are Identified
A name is a text string that, by default, consists of the simulation object category, as defined in the object parameter database, and an integer. For example, if you create a new scenario and add two M1A2 tanks and two Apache helicopters, the default names are M1A2 1, M1A2 2, USAtRW 1, and USAtRW 2. When VR-Forces generates a name, it picks an integer that makes the name unique. However, if you import a scenario into another one and do not specify that duplicate names be renamed, it is possible that more than one simulation object will have the same name.
You can edit a simulation object name to make it meaningful to you. Simulation object names have the following restrictions on their length:
Entities – 11 characters.
Units – 31 characters.
If you are using a character set that requires multiple ASCII characters to represent a visible character, entity and unit names will need to be correspondingly shorter.
An echelon ID is a text string that identifies the simulation object’s place in the force hierarchy. For example, the hypothetical entities in the previous section would be part of Blue force, or Force 1. The echelon ID for M1A2 1 would be 1 M1A2, 1 Force. The syntax of echelon IDs and the details of simulation object organization are described in “How Simulation Objects are Organized,” on page 15-6. You cannot edit a simulation object’s echelon ID. The echelon ID changes if you change the force hier- archy by adding, removing, or editing simulation objects.
You can also identify simulation objects using extended labels – additional text strings that you can give descriptive names to. For details, please see “Using Extended Labels,” on page 18-17.
In the VR-Forces GUI, entity labels refer to informational graphics displayed next to simulation objects. The label described in this section is one of the symbol decorations displayed in Plan View observer mode as part of the entity label. For more information about the different types of labels and information displays, please see “Displaying Entity Labels,” on page 18-9.
Introduction to Simulation Objects — How Simulation Objects are Organized
All simulation objects simulated by VR-Forces exist in the context of a hierarchy. At the top-most level, simulation objects are grouped according to force ID (friendly, opposing, neutral, and so on). At lower levels, simulation objects are grouped according to military organization, in which a simulation object has a designation in the hier- archy, such as 2nd Platoon, B Company. At each echelon level in the organization, a simulation object has a single superior simulation object. Disaggregated units contain one or more subordinate entities, units, or both. The hierarchy’s lowest level contains an individual entity.
In entity-level scenarios, units can be in an aggregated state or a disaggregated state. For details, please see “Units in Entity-Level Scenarios,” on page 22-2.
Each simulation object has an echelon ID in the following format:
designator [category] [echelon], designator [category] [echelon], ...,
force_number Force
where:
designator is a number or letter that differentiates the simulation object from other members of the echelon, such as 1 (M1A1), 2 (M1A2), and so on.
category is an optional descriptor for the simulation object, such as M1A2.
echelon is an optional descriptor for the organizational unit, such as “Platoon”.
force_number is the force the simulation object belongs to, based on the force type enumerations. The force is the highest level in the hierarchy.
When you create a new simulation object, it exists only within the default force. There- fore its echelon ID would be similar to:
M1A2, 1 Force
If a simulation object becomes part of a unit, the unit information becomes part of the echelon ID, and the designator may change, for example:
M1A2, 2 Plt, 1 Force
Introduction to Simulation Objects — How Simulation Objects Communicate
The category and echelon labels that make up an echelon ID, such as “M1A2”, “Plt”, and so on, are specified in the VR-Forces object parameter database and are associated with object-types. When you create a simulation object of a certain type, the echelon ID category and echelon name associated with that type are assigned to the simulation object. You cannot change the labels interactively. You can change the labels by editing the object parameter database.
Designators are assigned by VR-Forces. You have no direct control over them. When you create new simulation objects, they are assigned designators sequentially, starting with one (1). If you aggregate a group of entities, the unit leader is assigned the desig- nator 1, and the other entities in the unit are assigned successive designator numbers.
aggregate mode specifies that each unit has its own radio network. Messages sent from a simulation object can reach any simulation object that is in the same organization, at the same level (the simulation object’s peers in the organization), and can also reach the simulation object’s direct superior. All other simulation objects are outside the network, and are unable to receive messages sent by the simulation object. This is the default mode.
force mode specifies that there is a radio network for each force in VR-Forces. Messages sent from a simulation object can reach any other simulation object of the same force.
all mode specifies that all simulation objects in VR-Forces are part of one large radio network. In this case, any simulation object can receive messages sent by any other simulation object.
The communication model is configured in ./data/simulationModel- Sets/<sms>/CommModelParams.mtl. For details about configuring radios, please see “Configuring Radios,” on page 74-4.
VR-Forces includes an external communication model that can communicate with an external communication effects server to determine how to deliver radio messages. For details, please see Chapter 13, Using a Communications Effects Server.
Introduction to Simulation Objects — VR-Forces Uses a Component Architecture
You can create new communication models and install them in VR-Forces. This is useful if you want to define your own connectivity model, or write your own algo- rithms for determining if radio messages get delivered. For details, please see API docu- mentation.
VR-Forces simulation objects use a component architecture similar to that used in many robotics applications. There are three basic types of components supported: sensors, controllers, and actuators. Components communicate with each other through data ports and port groups, which may provide data as simple as a single number (such as a throttle value) or more complex data such as a list of simulation objects that have been detected. The port groups make it possible to multiplex and prioritize multiple data sources to a single data recipient. For example, the automotive actuator of ground vehicles can receive inputs from a collision-avoidance controller, move-to-point controller, and follow-route controller, but it does not want inputs from all of those controllers at once.
Simulation Object
Simulation Object
Sensor
Controller
Actuator
Sensor
Controller
Actuator
Entity State
Entity State
Figure 15-1. Simulation object component architecture
For more information, please see Appendix C, Object Parameters.
Introduction to Simulation Objects — VR-Forces Uses a Component Architecture
Sensor components provide models of the simulated environment, which are used by controller components to make decisions and perform tasks. The simplest sensor might provide (simulated) ground truth, while more sophisticated ones could use complex models for sensing electromagnetic emissions, RADAR, or a cognitive model to simu- late a soldier or crew member's perception of the simulated world. Sensor components can get information from:
The virtual network.
From a terrain database.
By monitoring the state of the simulation object model.
Many other potential sources. The use of sensors is optional.
Controller components typically provide control inputs to actuator components (although this is not required). Controllers can use information provided by sensors to perform their functions, but this is not a requirement either. For example, the controller that implements the various forms of the Wait task neither requires sensor information, nor provides control inputs to any actuators.
Actuator components:
Provide the physical model of the simulation object being simulated.
Change the simulation object’s state.
Interact with other simulation objects (such as by sending messages).
Generate events on the virtual network, such as detonations.
Modify the state of the simulation object: position, velocity, damage, and so on.
Actuators can also use data directly from a sensor, when modeled or filtered data is preferred over simulated ground truth for a model that does not require a controller.
Introduction to Simulation Objects — Simulation Object Behaviors and Tasks
A behavior is something that a simulation object knows how to do on its own. Behav- iors describe how a simulation object reacts to a specific condition or situation or how it performs a task. A task is something that you tell a simulation object to do. A simula- tion object does not innately know that it should move to a point. However, if you task it to move to a point, it knows how to locate the point and how to move to it.
Behaviors can override task assignments. For example, if an entity is moving along a route and detects another entity in its path, the collision-avoidance behavior overrides the movement task until the entity successfully avoids the obstacle and can return to moving along the route.
No semi-automated forces (SAF) system, such as VR-Forces, can completely emulate the behavior of a complex real world entity. The behaviors provided by VR-Forces handle the lower level activities necessary to complete a task, and allow you to focus on the higher level activities involved in assigning tasks and preparing plans.
VR-Forces supports two different approaches to modeling simulation objects – entity- level simulation and aggregate-level simulation.
In entity-level simulations, VR-Forces focuses on the interaction among individual entities, such as ships, tanks, automobiles, airplanes, and people. When you create a simulation object, you are usually creating one tank, one ship, or one human, and so on. Combat takes place between entities based on their weapon systems and their ability to withstand munitions.
In an entity-level simulation, you can combine entities into higher echelon units, such as platoons and companies, but when they engage in combat, they do so by modeling the interactions of their members at the individual entity level.
Aggregate-level simulations focus on the high level movement and interaction of large numbers of personnel and equipment in hierarchical units. For the most part, they do not model individual simulation object interactions and combat. When you create a simulation object, you are usually creating a company, or a brigade, and so on. Aggre- gate-level combat is modeled based on the relative strengths and weaknesses of simula- tion objects in personnel, equipment, and location, not on the engagement of individual entities.
Introduction to Simulation Objects — Entity-Level Modeling and Aggregate-Level Modeling
As in entity-level simulations, in an aggregate-level simulation, you can combine enti- ties and units into higher echelon units.
The type of modeling used in a scenario depends on the systems that simulation objects use, which are configured in the simulation model set it uses. If you use EntityLevel.sms or an SMS similar to it, it uses entity-level modeling. If you use AggregateLevel.sms, or an SMS similar to it, it uses aggregate-level modeling. Therefore, when you create a scenario, you must consider which type of modeling you want to use and you must remember which type of modeling you are using when you populate the scenario.
Aggregate-level modeling only works with HLA Evolved and MAK FOM extensions. (If you try to create a scenario with AggregateLevel.sms and you are using an unsup- ported protocol, VR-Forces displays an error message.) For a detailed discussion of the aggregate warfare model, please see Chapter 23, How Aggregate-Level Modeling Works.
AggregateLevel.sms has some simulation objects that represent individual entities. However, they use data-driven models that are different from those used by similar entities in EntityLevel.sms.
!
!
Although it is possible to create a scenario that uses both types of simulation model sets, the resulting behavior will be unpredictable, because simulation objects that use aggregate-level modeling cannot interact with simulation objects that use entity-level modeling. Combining these SMSs is not recommended and not supported.
Introduction to Simulation Objects — Entity-Level Modeling and Aggregate-Level Modeling
16. Creating and Placing Objects
This chapter describes generic procedures for creating and placing simulation objects and tactical graphics. The later chapters assume that you are familiar with these proce- dures.
Selecting the Object to Create 16-4
Selecting the Object to Create on an Object Palette 16-5
Selecting the Object to Create on the Create Menu 16-8
Placing an Object Using Default Values (Click to Create) 16-11
Specifying an Object’s Properties Before You Create It (Click to Locate) 16-13 Specifying an Object’s Altitude 16-14
Setting Altitude Dynamically 16-15
Setting Altitude in the Create Object or Edit Object Dialog Box 16-15
Specifying the Altitude for All of the Vertices in a Route 16-16
Specifying an Object’s Heading Dynamically 16-17
Locking the Mouse to the Object Being Created 16-18
Dragging an Object to a New Location 16-19
Copying and Pasting Objects 16-21
Pasting Specific Entity Characteristics 16-23
Simulation Object Groups 16-25
Creating Random Versions of Similar Entity Types 16-25
Creating and Placing Objects
Creating Cultural Features 16-26
Adding an Object to the Favorites List 16-27
Creating and Placing Objects — Creating Objects
VR-Forces lets you create simulation objects, cultural features, tactical graphics, and props. You can create simulation objects and cultural features from the Create menu or the Simulation Objects Palette. You create tactical graphics from the Create menu or the Tactical Graphics and Hazards/Obstacles palettes. You create props from the Props Palette. The procedure for creating an object is essentially the same regardless of the type of object:
Select the object that you want to create.
Specify the location and properties of the object.
However, there are several ways to select the object you want to create and several ways to specify an object’s location and properties. This chapter describes the different generic ways to create objects. Additional procedures specific to different object types are described in later chapters.
When you create an object, VR-Forces adds a tab to the right side of the window, below the object palettes. The tab is labeled Create object, where object is whatever object you selected to create. If you click that tab, it opens a dialog box that lets you specify the properties of the object you are creating. Table 16-1 lists the properties that you can set for each object type. You can also edit these same properties after you create an object.
Table 16-1: Editable object properties
Entity | Cultural Feature | Tactical Graphic | Prop | |
Force | X | X | X | |
Heading | X | X | ||
Label (and extended labels) | X | X | ||
Location | X | X | X | X |
Name | X | X | X | |
Overlay | X (Edit only) | X (Edit only) | X | |
Style | X |
You can select the object to create on the Create menu or on an object palette (Simula- tion Objects Palette, Tactical Graphics Palette, Hazards/Obstacles Palette, or Props Palette). Once you have selected the object, placing the object is the same regardless of how you started the process. For details, please see “Placing Objects,” on page 16-11.
The Create menu does not contain the full list of objects configured in VR-Forces. It only lists the simulation objects and tactical graphics that you have marked as “Favor- ites”. It gives you quick access to your most frequently used objects. For details, please see “Adding an Object to the Favorites List,” on page 16-27.
VR-Forces has the following object palettes that let you quickly choose the object that you want to create:
Simulation Objects Palette. Create simulation objects, cultural features, and build- ings.
Props Palette. Create props that can be saved as part of the terrain. (The default window layout does not display the Props Palette.)
Figure 16-1 shows the location of the palettes (with the Props Palette enabled).
Figure 16-1. Object creation palette tabs
To select the object to create on an object palette:
Click the tab for the palette you want to open. The palette is displayed (Figure 16-2).
By default, the palettes list all objects that can be created. You can filter the Simula- tion Objects Palette list by category, force, and country of use. You can filter the Tactical Graphics Palette and Hazards/Obstacles Palette by category and force. The Props Palette organizes props by category in a tree list.
Optionally, in the Categories list, select the category for the object you want to create, such as ground or fixed-wing for entities, or control objects for tactical graphics.
Optionally, filter the Simulation Objects Palette by selecting a country in the Used By list.
The Used By filter lists simulation objects of the selected Category that are used by the specified country. VR-Forces does not provide an exhaustive list of countries or the platforms that they use. You can add additional countries and categorize simulation objects in the Simulation Object Editor. For details, please see “Editing a Simulation Object’s Used By Countries List,” on page 65-9.
In the Force list, select the force for which you want to create this simulation object. All object types for a given platform are listed. There is no preconceived force for any of them.
In the list of objects, click the object that you want to create. The cursor changes to draw mode and a Create Object tab is added to the window. For details about draw mode, please see “Draw Mode,” on page 16-9.
Create the object, as described in “Placing Objects,” on page 16-11.
Ordinarily, after you select an object to create, the palette closes. However, you can pin the palette to keep it open so that you can select additional objects to create without needing to click the palette to reopen it. If you pin a palette, it becomes dockable and undockable and you can drag it off the window like the other panels. (For details about undocking panels, please see “Dockable Panels and Toolbars,” on page 78-2.)
To pin a palette so that it stays open after you select an object, click the pin button ( ) in the palette’s title bar (Figure 16-3).
Waypoints, routes, areas, and objects marked as Favorites are available on the Create menu.
To select the object to create on the Create menu:
To create an object or graphic, choose Create category object_type, where:
category is a category of entity, such as Ground or Human, a category of cultural feature, or a category of tactical graphic.
object_type is a specific type within the category, such as M1A2 or T80.
The cursor changes to draw mode and a Create Object tab is added to the window. For details about draw mode, please see “Draw Mode,” on page 16-9.
Create the object, as described in “Placing Objects,” on page 16-11.
When you create an object, the cursor changes to draw mode. If you are creating a simulation object or a cultural feature in the 2D view, the cursor changes to a 2D icon that represents the chosen simulation object(Figure 16-4).
Figure 16-4. 2D entity creation and Create object tab
In the 3D view, the cursor changes to the 3D model for the chosen entity (Figure 16-5). If you are zoomed out, 3D models may be hard to see. If you are creating multiple human characters of a type that randomizes the appearance of the character that gets created, such as Civilian Male, after each character you create, the model attached to the cursor changes to show you the appearance of the next character that will be created.
Top-down view as in Figure 2-1 Ground-level view
Figure 16-5. 3D entity creation
If you are creating a tactical graphic, the cursor displays the waypoint symbol when you create a point and a vertex symbol when you create any type of line or area. Figure 16-6 illustrates tactical graphics draw mode cursors.
Figure 16-6. Tactical graphics cursors in draw mode
If you are creating a prop, the cursor changes to show the model for the prop. In the 2D view, the model is a top down view and is proportional to the terrain, so it may be diffi- cult to see if you are zoomed out.
After you select the object that you want to create, the Create Object tab is added to the right side of the window below the Props Palette.
There are two basic methods for placing simulation objects, as follows:
Click to Create. Each mouse click creates an instance of the selected object. For multi-vertex tactical graphics, each click specifies a vertex. Click to Create is best for rapidly creating objects using the default values for the object’s properties.
The create object graphic is attached to the mouse cursor. Although you can use the Create Object dialog box to specify an object’s name or other properties, as you move the cursor into the dialog box, the creation location (as represented by the object graphic) moves with it, which can be disconcerting. You can set heading and altitude dynamically, so there is no need to use the Create Object dialog box for these properties.
If you want to explicitly set the object’s location, and particularly if you want to set the altitude relative to sea level, you must use this method. This method may also be more comfortable for persons who want to take a deliberative approach to spec- ifying an object’s properties before creating it.
Although you can specify an object’s properties using the Click to Create method, it is best suited for quickly creating objects using default properties. Objects are placed on the default overlay for the object type.
You can use this method to automatically embark simulation objects and attach tactical graphics. For details, please see “Embarking and Disembarking Simulation Objects Instantly,” on page 19-8 and “Attaching a Tactical Graphic Automatically,” on page 39-11.
Creating and Placing Objects — Placing Objects
To place an object with each mouse click:
Select the object that you want to create as described in “Selecting the Object to Create,” on page 16-4. A Create object tab is added to the side of the window below the Props Palette.
For simulation objects and waypoints, click on the terrain for each object you want to place. You can create multiple single point objects without exiting create mode. For details about disabling this create mode, please see “Locking the Mouse to the Object Being Created,” on page 16-18.
For multi-vertex tactical graphics, click on the terrain to place each vertex. Right click to place the last vertex in a route or area. (Do not try to close areas by clicking on the starting point. Doing so only creates another vertex near the first one.)
To draw a circles, ellipses, boxes, or text, please see the sections in Chapter 39,
Creating and Editing Tactical Graphics.
!
!
If new objects or vertices do not get displayed as you click, it is possible that Attach Object to Mouse is disabled. To restore Click to Create mode:
Click the Create Object tab. The Create Object dialog box opens.
Select the Attach Object to Mouse check box.
If tactical graphics are not displayed after you create them, check to see if the display of tactical graphics has been disabled. For details, please see “Displaying Tactical Graphics,” on page 37-6.
Optionally, you can set the altitude of an object as you create it. For details, please see “Setting Altitude Dynamically,” on page 16-15.
Optionally, you can set the heading of an object as you create it. For details, please see “Specifying an Object’s Heading Dynamically,” on page 16-17.
If you want to specify any of the object’s properties in the Create Object dialog box while using Click to Create, you can do so. However, be aware that as you move the cursor into the dialog box, the object graphic will move also. Once you specify the desired properties, click on the terrain to create an object with those properties. The properties will be applied to any additional objects you create until you change them or close the dialog box.
Right-click or press Esc to exit create mode.
In the Click to Locate method, clicking on the terrain sets the coordinates of the object, but does not create it. You can specify all of the object’s properties in the Create Object dialog box before creating it. Table 16-1 lists the properties that you can set for the different types of objects.
To specify the properties of an object when you create it:
Select the object that you want to create as described in “Selecting the Object to Create,” on page 16-4. A Create Object tab is added to the window below the palettes (Figure 16-4).
Click the Create Object tab. A Create Object dialog box that is appropriate for the object opens (Figure 16-9).
Figure 16-7. Create Object dialog boxes
Clear the Attach Object to Mouse check box. For details about this option, please see “Locking the Mouse to the Object Being Created,” on page 16-18.
To specify the object’s name, type a name in the Name box. For details about how simulation objects are named, please see “How Simulation Objects are Identified,” on page 15-3.
Optionally, specify a label.
Optionally, if extended labels are available, specify them. For information about extended labels, please see “Using Extended Labels,” on page 18-17.
To specify the object’s heading, type or select a value, in degrees, in the Heading box.
To specify the overlay on which to place an object, select an overlay from the Overlay list.
Specify a force.
To specify a simulation object or point object’s coordinates, click on the terrain or type coordinate values in the dialog box. To specify the altitude, follow the proce- dure in “Specifying an Object’s Altitude,” on page 16-14.
To specify the vertices of a route or area:
Click on the terrain to place the first vertex, or type the coordinates in the dialog box.
Click the Add button ( ) to add a vertex.
Click to locate the vertex or type the coordinates.
Continue adding vertices until you are finished specifying the route or area. You can insert vertices anyplace in the object by selecting an existing vertex and clicking the Add button.
To draw circles, ellipses, boxes, or text, please see Chapter 39, Creating and Editing Tactical Graphics.
For tactical graphics, specify whether or not to publish the object.
Click Create. The object is created. You can continue to create additional objects of this type.
To close the dialog box, click Close.
You can specify an altitude for air platforms, sub-surface entities, the vertices of waypoints and routes, and props when you create them or edit their properties. (You can also set altitude for simulation objects using the Location set data request, Fly Alti- tude tasks, and the Move to Location task. You can set altitude dynamically or in the various dialog boxes for setting object properties or actions.)
Creating and Placing Objects — Specifying an Object’s Altitude
You can set altitude dynamically for simulation objects that support an altitude, for waypoints, for individual vertices of a route, and for props that have not been saved into a terrain. When you set altitude dynamically, it is set relative to the terrain.
To set altitude dynamically:
If you are creating an object, press and hold Alt and scroll the mouse wheel, or press and hold Alt+left mouse button and drag the mouse.
If you are editing a simulation object or vertex:
Double-click the object to make it editable.
Press and hold Alt and scroll the mouse wheel, or press and hold Alt+left mouse button and drag the mouse.
Click to set the new altitude.
When you set altitude in a dialog box, you have the following options:
Above Sea Level. The distance above sea level. If the terrain is higher than the alti- tude entered, the entity will be below the surface of the ground.
Above Terrain. The distance above the terrain at this location.
If you are creating or editing a route, you can adjust the altitude of all of the vertices at the same time and in the same way. For details, please see “Specifying the Altitude for All of the Vertices in a Route,” on page 16-16.
To set altitude in a dialog box:
If you are creating or editing an object:
Click the Create Object (or Edit Object) tab. A dialog box opens.
Clear the Attach Object to Mouse check box. The Location group box becomes enabled. (Although the entity will change its location as you move the cursor into the dialog box, it snaps back to its original location as soon as you clear the check box.)
In the Altitude group box, select one of the options.
Type an altitude in the box.
When you create a route or edit its vertices, you may want to change the altitude of all of its vertices in a similar way. VR-Forces lets you:
Adjust all vertices by the same amount.
Set all vertices to the same height above sea level.
Set all vertices to the same height above the terrain.
To change the altitude for all of the vertices in a route:
If you are creating a route, open the Create Route dialog box. If you are editing a route:
Select the route.
Choose Objects Edit. The Edit Route dialog box opens.
Click the Adjust Points button ( 
). The Adjust All Points dialog box opens (Figure 16-8).
Select the adjustment action as follows:
Adjust Altitude By. Changes the altitude of each vertex by the amount specified in the Altitude box.
Set Altitude Above Sea Level. Sets the altitude of each vertex to the amount above sea level specified in the Altitude box. This could result in some vertices being below ground.
Set Altitude Above Terrain. Sets the altitude of each vertex the amount above the terrain specified in the Altitude box.
Type the desired altitude adjustment value in the Altitude box.
Click OK.
Creating and Placing Objects — Specifying an Object’s Heading Dynamically
When you create a simulation object, cultural feature, or prop, you can set its heading in the Create Object dialog box, or dynamically. Afterwards, you can edit a simulation object or cultural feature’s heading directly or use the Heading set data request. (For more information, please see “Heading,” on page 34-23.)
To set an object’s heading dynamically as part of the creation process, hold down the Shift key and the left mouse button, and drag the mouse.
Creating and Placing Objects — Locking the Mouse to the Object Being Created
However, if you want to use the Create Object dialog box to specify location or other properties for each object as you create it, this feature can be inconvenient because as you move the mouse to the Create Object dialog box, the placement location changes with the mouse movement. Disabling this feature can give you greater control over the creation process, because clicking to set the location of the object or a vertex does not create it – it sets the coordinates, but lets you make further changes in the Create Object dialog box before you create the object.
If you disable an object’s attachment to the mouse when you are creating objects, you create them by clicking Create in the dialog box rather than clicking on the terrain.
To enable or disable the mouse’s attachment to the creation location, in the Create Object or Edit Object dialog box, select or clear the Attach Object to Mouse check box (Figure 16-9). When you clear the check box, a Create button gets added to the dialog box. The setting gets carried over to future object creations.
Figure 16-9. Create Object dialog box
Creating and Placing Objects — Moving Objects
For information about setting the location of a simulation object, please see “Location,” on page 34-26.
i You can only move objects simulated by VR-Forces.
When you move objects, they are centered on the mouse location as follows:
If you select an object by double-clicking, it attaches to the mouse at the location where you clicked it. (For simulation objects and point objects, the objects are centered on the mouse location, but for lines or areal objects, the attachment is at the point where you clicked.)
If you select an individual object and move it by choosing the Move command:
Point objects are centered on the mouse, just as when you double-click them.
Routes attach to the mouse cursor at the first point of the route (Figure 16-10).
Areas attach to the cursor at the center of mass.
Double-click drag Move command drag
If you select multiple objects and move them by choosing the Move command:
Point objects attach to the cursor at their center of mass.
Multiple objects have their centers of mass averaged and the center point attaches to the cursor (Figure 16-11).
Creating and Placing Objects — Moving Objects
Figure 16-11. Moving multiple objects
If you click the terrain and then Shift+click or Ctrl+click an object, the terrain is selected and the Move command will not be available.
To drag an object from one point on the terrain to another:
Double-click the object, or select the object and choose Objects Move.
Move the mouse to change the location of the object.
Left-click the mouse.
i You can drag multiple objects and they can be of different types.
To drag multiple objects, you must select the objects and choose
Objects Move.
To cancel a move made by dragging an object, press Esc before you click the left mouse button.
VR-Forces copies the following data about an object:
Environmental objects:
Original name.
Label.
Force.
Color.
Entities:
Original name.
Label.
Force.
Heading.
Appearance (lights, landing gear, and so on).
Rules of engagement.
Plan.
Units copy the same information as entities plus the list of subordinates. VR-Forces does not copy:
The current task.
State information, except as noted previously.
Load balancing status. All objects get pasted into the currently selected back-end.
Embarkation structures. If, for example, you copy an aircraft carrier that has planes embarked, only the carrier is copied, not the embarked entities.
!
!
To copy objects:
Select the objects you want to copy.
Choose Objects Copy.
A simple paste pastes all of the attributes of an object that get copied. It pastes objects as follows:
Tactical graphics are placed on the currently selected overlay. If you copied objects that were on different overlays, that differentiation is not preserved.
Copied objects maintain the state at the time that they were copied. Therefore, if you paste objects some time after they were initially copied, the copies do not reflect any changes that may have taken place to the original simulation objects. For example, if a simulation object was copied and then deleted, the copied version of the entity is still pasted.
Embarkation structures are not copied, only the parent entity.
!
!
Pasting plans may have unexpected consequences, because their object references do not change when you copy them. For example, suppose the plan for Entity A refers to Waypoint 1. You copy Entity A and Waypoint 1 and paste them as Entity B and Waypoint 2. If you copy the plan, Entity B’s plan will still refer to Waypoint 1. If you expected it to refer to Waypoint 2, you will not see the behavior you expected. You can choose not to paste plans. For details, please see “Pasting Specific Entity Characteristics,” on page 16-23.
To paste objects:
Choose Objects Paste. The objects in the paste buffer are displayed on screen. They float as you move the cursor to show you where they will be placed when you paste them.
Click on the terrain where you want the objects to be pasted. They are pasted in the relative positions in which they were copied. If an object has an altitude, it is pasted using the same altitude above the terrain as the original object.
Optionally, continue pasting additional copies if desired.
Right-click to exit paste mode.
When you paste simulation objects, you can specify which of the following entity char- acteristics you want to paste with the entity:
Appearance.
Heading.
Rules of engagement.
Entity name.
Altitude. You can specify that the previous altitude be applied as above terrain or as above sea level.
To paste particular entity characteristics:
Choose Objects Paste Special. The Paste Special dialog box opens.
Figure 16-12. Paste Special dialog box
By default, all check boxes are selected. Clear the check boxes for the options you do not want to paste.
Choose the altitude option that you want to use.
Click OK. The objects in the paste buffer are displayed on screen. They float as you move the cursor to show you where they will be placed when you paste them.
Click on the terrain where you want the objects to be pasted. They are pasted in the relative positions in which they were copied.
Optionally, continue pasting additional copies if desired.
Right-click to exit paste mode.
When you paste objects, if the pasted object can have an altitude value, such as a fixed- wing entity, a waypoint, or the vertices of a route, the default behavior is to replicate the original altitude above the terrain. If you use the Paste Special operation, you can choose to apply the original altitude as being above sea level. Figure 16-13 illustrates these alternatives. A waypoint is placed on the terrain. It is 0 meters above the terrain. However, the terrain itself is 200m above sea level. If the waypoint is copied and pasted at point A and the altitude above the terrain is maintained, the point is placed at 0m above the terrain. If the point is pasted at point B and altitude above sea level is main- tained, it is placed 200m above sea level.
Original
200m
Copy
A B
Figure 16-13. Pasting altitude
Creating and Placing Objects — Creating Random Versions of Similar Entity Types
Simulation object groups (SOG) are a convenient mechanism for creating reusable configurations of simulation objects and tactical graphics. You create them in the Simu- lation Object Editor and they are listed on the Simulation Objects Palette with other simulation objects. VR-Forces places them in the relative positions that you specified when you created the SOG. VR-Forces includes example SOGs, including a carrier group, a Patriot missile battery, and a barracks with several soldiers. These examples demonstrate SOGs with tactical graphics, cultural features, and embarkation.
The Barracks With Guards SOG has some tactical graphics, but they are hidden by default. To see them, click the overlay icon at the bottom of the window, or select the check box on the Objects List Panel, Overlays tab.
For information about creating SOGs, please see “Creating a Simulation Object Group,” on page 65-45.
VR-Forces has many different models for generic types of entities, such as a civilian vehicles or commercial aircraft. When you are creating a scenario with these sorts of entities, you can choose the specific entity types you want to use. However, if you want to quickly populate a scenario with a variety of similar objects, it is simpler to just let VR-Forces randomly create instances of the generic entity. This is done using the random simulation object.
A random simulation object is configured in the Simulation Object Editor with a list of specific simulation object types that it can draw from. When you create a scenario, you choose the random entity type on the Simulation Objects Palette and when you click on the terrain to place the object, VR-Forces picks a specific simulation object from the list.
The random simulation objects provided with VR-Forces are:
Civilian vehicle.
You can add your own random simulation objects in the Simulation Object Editor.
Creating and Placing Objects — Creating Cultural Features
Cultural features are objects that you can add to a scenario to simulate human artifacts such as buildings, bridges, and so on. They are in the Building and Cultural Feature categories on the Create menu and the Simulation Objects Palette. You add them to a scenario the same way you would add a simulation object. Cultural features are listed in the Objects List Panel. You can apply some set data requests to them, such as Location and Heading.
!
!
Some of the choices on the cultural feature lists are the same as those available on the Props Palette. However, cultural features are not the same things as props. Props are terrain objects and can be saved as part of a terrain. Cultural features are not part of the terrain, they are a type of simulation object and are saved in the order of battle file.
Props are terrain objects that you can select independently of the terrain. “Extracting Props from a Terrain Patch,” on page 55-20 explains how to create them by extracting them from a terrain or a feature layer. However, you can also create them from the Props Palette, similarly to how you create simulation objects. This is a valuable feature if your terrains do not have any features that you can extract as props. However note the following important details:
Props are not saved in a scenario. If you want to save a prop, you must save the terrain. You can save the terrain to a different name or overwrite the existing terrain. The next time you open the terrain, the prop will be part of it.
When you create a prop, the back-end does not know anything about it, because it is a terrain object. To have the back-end take the prop into account, you must save the terrain (as mentioned in the previous paragraph) and restart the scenario.
You can also create cultural features that look exactly like the props that you can create. However cultural features are not the same things as props. Cultural features are treated like simulation objects. They are listed with simulation objects and tactical graphics and get saved as part of the scenario.
The list of props that you can create from the Props Palette is based on the model definitions defined on the Model Definitions tab of the Visual Model Editors dialog box. Therefore, you can add new props to the Props Palette by adding new model definitions. For details, please see “Adding Object Models as Props,” on page 83-13.
Creating and Placing Objects — Adding an Object to the Favorites List
As mentioned in “Selecting the Object to Create,” on page 16-4, the Create menu does not include all of the objects that you can create. It just lists the objects that you have designated as “Favorites”. When you specify that a simulation object or tactical graphic be a favorite, it is automatically added to the Create menu.
The favorites list is specific to a simulation model set. It is saved to ./data/simulation- ModelSets/<model_set>/gui/favorites.mst. You can copy the file to other instances of VR- Forces or future releases and your favorites list will be enabled.
To add or remove an object from the Favorites list:
Open the palette that has the object you want to add to the Favorites list.
Select the category for the object you want to add to the Favorites list.
Click the star to the left of the object’s name.
Creating and Placing Objects — Adding an Object to the Favorites List
This chapter describes ways to select simulation objects and tactical graphics.
Selecting Simulation Objects, Tactical Graphics, and Props 17-4
Selecting Objects in the Window 17-5
Selecting Objects in the Objects List Panel 17-6
Selecting a Simulation Object in the Object Console Summary Panel.. 17-6 Unselecting Objects 17-7
Creating a Selection Group 17-8
Selecting a Selection Group 17-9
Adding Objects to a Selection Group 17-10
Removing Objects from Selection Groups 17-10
Renaming a Selection Group 17-10
Deleting a Selection Group 17-10
Selecting Objects — The Objects List Panel
There is a great deal of similarity in how you select, move, and view the different types of objects. You can manage them on the terrain, to some extent from the keyboard, and in the Objects List Panel, which is the central repository of object information.
The Objects List Panel has the following views:
Simulation object list: displays simulation objects in the simulation (Figure 17-1).
Echelon view: displays the simulation object hierarchy (Figure 17-2).
Embarkation view: displays the embarkation relationships of simulation objects (Figure 17-2).
Overlays view: lists overlays and the objects that are on them (Figure 17-3).
Selection groups view: lists selection groups and their members (Figure 17-3).
Figure 17-1. Objects List Panel – Simulation Objects list and Environmentals list
Figure 17-2. Objects List Panel – Echelon View and Embarkation View
Figure 17-3. Objects List Panel – Overlays view and Selection Groups view
VR-Forces displays the following kinds of objects that you might want to select:
Simulation Objects. Any of the entity and unit types that you can create.
Cultural features. Objects in the Building and Cultural Feature categories on the Simulation Objects Palette.
Tactical graphics. Control objects and the points, lines, areas, text, and symbols on the Tactical Graphics Palette, Hazards/Obstacles Palette, and Create menu.
Props. Any of the props that you can create from the Props Palette or which are already part of the terrain.
You can select all types of objects in the window. You can select simulation objects, cultural features, and tactical graphics in the Objects List Panel (Figure 17-1). You can select simulation objects in the Object Console Summary Panel, and you can select props on the Props page of the Terrain Settings dialog box (Figure 17-4).
Figure 17-4. Terrain Settings dialog box, Props page
When you select a simulation object or tactical graphic in the 2D view, its border color changes to white. In the 3D views, all selected 3D objects display a bounding box (Figure 17-5). Tactical graphics change to white lines.
2D 3D
To select objects in the window, use any of the following mouse actions:
Mouse Action Result
Click the object. Selects an object (and unselects any other selected
objects).
Ctrl-click the object. Selects an object while keeping existing selections. Double-click the object. Selects the object and makes it editable. This is the equiv-
alent of selecting an object and choosing
Objects Edit.
Alt-drag a bounding box.
Selects multiple objects by dragging a selection box around them.
Right-click the object. If no objects are selected, right-clicking selects an object
and displays a menu.
If one or more objects are selected, right-clicking a selected object maintains the selection and displays a menu. Right-clicking an unselected object changes the selection to the object you right-clicked.
When you select an object in the window, the views on the Objects List Panel add a gray highlight to the entry for the object to indicate that it is selected.
To select an object in the Objects List Panel:
Locate the object you want to select. You can filter the list to make it easier to find particular objects. (For details, please see “Filtering the Object Lists,” on
page 17-6.) Disaggregate and expand units if necessary. (For details, please see “Expanding and Collapsing Units,” on page 25-2 and “Triggering Unit State Tran- sitions,” on page 24-11.)
Click the entry for the object. The selected object is highlighted in the Objects List Panel and on the terrain.
Optionally, select multiple objects, as follows:
Shift-click to select a contiguous range of simulation objects.
Ctrl-click to select multiple non-contiguous simulation objects.
You can filter the display in the Entities List and the Environmental List.
To filter the display of objects, select a category to view from the list at the top of the tab (Figure 17-1).
The Object Console Summary Panel lists messages that have been sent to simulation objects from the simulation engine, from a simulation object’s plan, from other simula- tion objects, and from scripts. (For information about the Object Console Summary Panel, please see “Configuring Object Console Messages,” on page 18-31.)
To select a simulation object in the Object Console Summary Panel:
Right-click a message from the simulation object you want to select.
On the popup menu, choose Select Entity.
To unselect objects in the window, choose one of the options in Table 17-1.
Table 17-1: Unselecting objects on the terrain
Action Result
Action Result
Click in the window away from the selected object or objects.
Unselects all objects.
Right-click. Exits edit mode, but object remains selected.
Click a selected object. If multiple objects were selected, unselects all
except the object you clicked.
Ctrl-click a selected object. Unselects the object. If multiple objects were
selected, does not unselect other objects.
To unselect objects on the Objects List Panel, choose one of the options in Table 17-2.
Table 17-2: Unselecting objects in the Objects List Panel
Action Result
Action Result
If one object is selected. Ctrl-click the object.
If a group of objects is selected:
Ctrl-click an object. Unselects the object without affecting other selections. Click an object. Selects the clicked object and unselects all other objects.
Selection groups are named subsets of the objects in an exercise. Their purpose is to allow you to quickly select specific objects without needing to locate them on the map or the Entity List in the Objects List Panel and select them individually. Using selection groups can be helpful if you want to quickly select a group of objects that do not fit neatly into the default filter options on the Objects List Panel tabs, for example a mix of friendly and opposing forces and tactical graphics. The group definitions are saved and loaded as part of the scenario.
An object can be in multiple selection groups.
You can create selection groups in any of the following ways:
In the Selection Groups view on the Objects List Panel.
From Selection Groups menu options.
Using keyboard shortcuts.
When you add a simulation object group to a scenario, VR-Forces automatically creates a selection group for all the objects in the simulation object group. For information about simulation object groups, please see “Simulation Object Groups,” on page 16-25.
To create a selection group in the Selection Groups Panel:
On the Objects List Panel, select the Selections Groups view (Figure 17-6).
Figure 17-6. Selection Groups tab
Click the Add button ( ). The New Selection Group dialog box opens.
Type a name for the selection group.
Click OK. The group is added to the group list.
To create selection group from a Selection Group menu command:
Select the objects you want to put in a new selection group.
Choose Objects Selection Groups Add to New Selection Group. The New Selection Group dialog box opens.
Type a name for the selection group.
Click OK. The selection group gets created and the selected objects get added to it.
You can quickly create a selection group with a default name using a keyboard shortcut. When you create a selection group from the keyboard it is created as follows:
If no objects are selected, an empty selection group is created.
If objects are selected, a selection group is created with these objects as members.
If the keyboard shortcut is for a selection group that already exists, a new selection group replaces the previous one. If the previous group had members and the new one is created without any objects selected, the new group is empty.
To create a selection group from the keyboard, press Ctrl + number, where number is 1, 2, 3, 4, 5, 6, 7, 8, 9, or 0. A selection group is created named Selection Group number (0 creates Selection Group 10). (The keypad numbers do not support this operation.)
When you select the objects in a selection group, they are selected in the views on the Objects List Panel and in the display window.
To select a selection group, use one of the following methods:
In the Selection Groups view, select a selection group in the Group list.
Choose Objects Selection Groups Select Selection Group group_name, where group_name is one of the groups listed on the pull right menu.
If selection groups named with the format Selection Group number exist, pressing a number key selects the corresponding selection group. (The keypad numbers do not support this operation.)
To add objects to a selection group:
Select the objects you want to add to a selection group.
Do one of the following:
Choose Objects Selection Groups Add To Selection Group group_name, where group_name is one of the groups listed on the pull right menu.
On the Selection Groups view, click the Add Current to Selection Group button ( ).
There are two ways to remove an object from a selection group. If you remove all the objects from a selection group, the group continues to exist.
To remove an object from a selection group:
Select the objects you want to remove from a selection group.
Choose Objects Selection Groups Remove from Selection Group
group_name, where group_name is one of the groups listed on the pull right menu.
To remove an object from a selection group in the Selection Groups view:
Select the selection group from which you want to remove an object.
Select the object you want to remove.
Click the Remove Selected from Selection Group button ( ).
To rename a selection group:
Type a new name for the selection group.
Press Enter.
Deleting a selection group does not delete the objects from the scenario. However, if you delete all the members of a selection group, the selection group also gets deleted.
To delete a selection group:
In the Selections Group view, select the group you want to remove.
Click the Delete button ( ).
18. Viewing Information about Objects
This chapter describes how to get information about simulation objects.
Displaying Information About an Object 18-3
Information Dialog Boxes for Entity-Level Scenarios 18-3
Information Dialog Boxes for Aggregate-Level Scenarios 18-6
Information Dialog Boxes for Tactical Graphics 18-8
Viewing Information for Multiple Objects 18-9
Displaying Text Labels for 3D Models 18-12
Turning Entity Labels On and Off 18-13
Pinning 3D Text Labels to the Window 18-13
Displaying Labels for 2D Icons 18-14
Configuring Shadowing and Background Color for 2D Labels 18-16
Adding an Extended Label 18-18
Changing an Extended Label’s Index 18-19
Deleting an Extended Label 18-19
Changing the Size of 2D Icons 18-21
Rotating 2D Icons to a Simulation Object’s Heading 18-22
Displaying HAT Lines for Entities (3D Only) 18-23
Displaying Threat and Sensor Range Rings 18-24
Enabling and Disabling the Display of Range Rings 18-26
Pinning Range Rings for a Simulation Object 18-26
Configuring the Display of Range Rings 18-27
Displaying Entity Resources 18-29
Viewing Information about Objects
Viewing Numerical Resource Data 18-29
Displaying Bounding Volumes 18-30
Showing Bounding Volumes Only for Selected Simulation Objects ... 18-31 Configuring Object Console Messages 18-31
Setting the Notification Level for Console Messages 18-32
Viewing All Console Messages 18-33
Answering Questions from Scripted Tasks 18-34
Displaying an Object Console Warning Icon 18-35
Clearing the Object Console 18-35
You can display information about individual objects, including entities, units, environ- mental objects, and Stealths. You cannot edit this information. You can also display entity labels. For details about entity labels, please see “Displaying Entity Labels,” on page 18-9.
To display an object information dialog box:
Select an object.
Choose Objects Information, or press i.
i You can also open the Information dialog box as follows:
Select a message in the Objects Console Summary Panel and choose
Information on the popup menu.
Click any field in the summary panel to open the relevant dialog box page.
Click the Information button 
) on the Last Selected Object Panel to open the State Data page.
Click the current task on the Last Selected Object Panel to open the Information dialog box to the Tasks page.
An information dialog box in an entity-level scenario (Figure 18-1) has the following sections:
Summary:
Simulation object icon.
Simulation object name.
Current task.
Sensor information.
Speed.
Altitude.
Health and weapon status.
Detailed information.
Object console.
You can expand and contract the detailed information and object console sections to manage the amount of screen space used by the dialog box.
Figure 18-1. Information dialog box for simulation object in entity-level scenario
The Detailed Information section for simulation objects in an entity-level scenario has the following pages:
State Data. Shows location, movement values such as speed and heading, identi- fying information, and other status information.
Appearance. Shows the status of appearance attributes, such as lights, firepower, and concealment.
Resources. Shows that amount of fuel and ammunition available.
Sensor Information. Shows information about simulation objects being detected.
Emitters. Shows details about emitters, if applicable.
Acoustics. Shows details about active sonar and propulsion noise, if applicable.
IFF. Shows IFF information, if applicable.
The pages listed for Detailed Information are context sensitive. If a page does not apply to an entity type, it is not shown.
The Detailed Information section for units in entity-level scenarios (Figure 18-2) has the following pages:
Tasks.
State Data.
IFF.
Subordinates. Lists the subordinates.
Acoustics.
Embarkation.
Figure 18-2. Information dialog box for units in entity-level scenarios
An information dialog box for units in an aggregate-level scenario (Figure 18-3) has the following sections:
Summary:
Simulation object icon.
Simulation object name.
Current task.
Sensor information.
Posture.
Health status.
Health and weapon status gumballs.
Detailed information.
Object console.
Figure 18-3. Information dialog box for simulation object in aggregate-level scenario
The summary section for units in aggregate-level scenarios (Figure 18-3) includes gumball icons that display information about the health of the simulation object. Simu- lation object icons also display gumballs.
Figure 18-4 describes the status represented by different gumball states.
No problems
Some problems
Major problems
Personnel Ammunition Weapons
POL (fuel)
Unable to complete mission
Green: 85% or better Yellow: 70 - 84%
Red: 50 - 69%
Black: less than 50%
White: Not applicable or no information
Figure 18-5 illustrates gumball charts for a simulation object icon.
Figure 18-5. Icon with gumballs
The Detailed Information section for simulation objects in aggregate-level scenarios has the following pages:
Tasks.
State Data.
IFF.
Subordinates. Lists the subordinates.
Personnel and Equipment. The types of personnel and number of each. Casualties, by category.
Supplies. Food, water, fuel, and ammunition. The Supplies tab displays informa- tion when a simulation object is receiving supplies or providing them to another simulation object. When a simulation object is receiving supplies, an up arrow is displayed next to the supply it is receiving.
Combat Capability. Combat power by category (anti-air, anti-personnel, and so on) and defensive capability, by category.
Engagements. Current attack and defense status.
Sensor Information. The Sensors tab shows information about simulation objects being detected. The Jamming tab shows if the simulation object is being jammed (electronic warfare) or is jamming other simulation objects.
Emitters.
Acoustics.
Embarkation.
The detailed information section for an environmental object (Figure 18-6), such as a route, has the following pages:
State Data. Shows the force and coordinates.
Attached To. The simulation object this object is attached to, if any.
Figure 18-6. Environmental object information dialog box
You can select multiple objects and view summary information for all of them. From the summary information window, you can jump directly to an object and you can open its Information dialog box.
To view information about multiple objects:
Select the objects.
Choose Objects Information, or press i. The Multiple Object Information window opens (Figure 18-7).
To zoom to the extents of an object, click its icon.
To open an Information dialog box for an object, click any of the details about the object, such as its name.
VR-Forces provides extensive information about simulation objects in the Information dialog box (“Displaying Information About an Object,” on page 18-3). It also provides an abbreviated set of information in the form of simulation object labels.
For 3D models, VR-Forces displays labels that help you locate and identify entities (Figure 18-8). The label consists of a locator circle, which is always visible when labels are enabled, and a text label that is displayed when you mouse over an entity. All entities within the view have locator circles, whether the model is visible or not. The color of an entity’s label represents its force – blue for friendly, red for opposing, and green for neutral.
A 3D text label displays the entity’s:
Entity type enumeration
Force
Name
Speed
Heading
Latitude and longitude
Altitude.
You can configure the attributes of the entity label, such as font size, and the height and width of the background by editing the entityInfo model definition in the Visual Models Editor. For details about editing model definitions, please see “Creating and Editing Model Definitions,” on
Entity locator
3D text label
Figure 18-8. Entity labels for 3D models
For 2D icons, labels are a set of individually enabled text labels, called symbol decora- tions (Figure 18-9). Entity labels for 2D icons are supported both in the 2D view and the 3D view. If you resize 2D icons, the labels also get resized. 2D icons can display the simulation object’s:
Acceleration.
Altitude above mean sea level.
Heading Indicator.
Label. If extended labels exist, each label can be displayed separately.
Location.
Name.
Orientation.
Velocity.
Weather. Cloud state, precipitation intensity, visibility, wind direction, and wind speed.
If spot reports are enabled, you can display labels for spot reports. For details, please see “Displaying Labels for Spot Reports,” on page 9-9.
Figure 18-9. Label for a 2D icon
To view a 3D text label, use one of the following methods:
Move the cursor over the circle that represents the entity.
On the Display Settings dialog box, Entity Display Settings page, select Show Information Only For Selected Entities (Figure 18-10). Then select the entity whose label you want to see.
Figure 18-10. Display Settings, Entity Display Settings page
To turn the display of entity labels on or off:
Choose Settings Display. The Display Settings dialog box opens.
Select or clear the Show Entity Labels check box.
You can also enable and disable entity labels by choosing Settings Entity Labels or by clicking the Entity Labels button ( ) on the Display Settings Toolbar.
You can pin 3D text labels to the window, making them stay visible after you move the cursor away from the entity.
To pin a 3D text label to the window or hide a pinned label:
Right-click an entity’s locator circle. A menu is displayed.
Choose Toggle Pinned Label.
You can display multiple text labels at one time.
To pin multiple text labels use either of the following methods:
Right-click and choose Toggle Pinned Label for each entity whose label you want to pin.
On the Display Settings dialog box, Entity Display Settings page, select Show Information Only For Selected Entities (Figure 18-10). Then, in the Objects List Panel, multi-select the entities whose labels you want to see.
You can enable and disable the display of labels for 2D icons by label type. This allows you to control how much screen space is taken up by the labels. You can control the display of labels in the Display Settings dialog box or on the Display Settings Toolbar.
To enable and disable display of 2D icon labels:
Choose Settings Display. The Display Settings dialog box opens.
Select the Symbol Decoration Settings page (Figure 18-11).
Select the check box for each label that you want to display. Clear the check box for each label that you want to hide.
To change the color of 2D labels:
Choose Settings Display. The Display Settings dialog box opens.
To set the color to any color:
Click the Foreground Color color swatch. A color picker dialog box opens.
Select the color you want to use.
Click OK.
To enable or disable 2D labels on the Display Settings Toolbar:
Click the arrow on the Entity Labels button 
). A small panel is displayed. It is a persistent window.
Figure 18-12. Symbol Decoration Panel
Select the symbol decorations that you want to display. Clear the ones you want to hide.
To hide the Symbol Decorations Panel, click the arrow on the Entity Labels button.
2D labels are drawn on a background that, by default, is transparent. However, you can increase the opacity of the background to make it visible and can change the back- ground color.
You can add shadowing to the text of 2D labels. This may improve visibility when simulation objects are on light colored terrain.
Figure 18-13. 2D label with background
To set the color and opacity of the 2D label background:
Choose Settings Display. The Display Settings dialog box opens.
To change the opacity of the background, adjust the Background Opacity slider.
To change the color of the background:
Click the Background Color color swatch. A color picker opens.
Select the color you want to use for the background.
Click OK.
To configure shadows for 2D labels:
Choose Settings Display. The Display Settings dialog box opens.
Select or clear the Shadow Text check box.
One of the ways to identify a simulation object is by its label. (For more information, please see “Labels,” on page 15-5.) Extended labels are additional labels that you can specify on an application-wide basis and define individually for simulation objects. The contents of each label gets sent over the network as part of the simulation object’s infor- mation and is displayed in its Information dialog box.
You can add and remove extended labels and change the label name. Changing a label’s name does not affect the text that is associated with the label for those simulation objects that use the label.
Extended labels are not scenario-specific. They affect all scenarios. Therefore, if you change a label’s name or index, or delete it, be sure that you want this change to apply to all scenarios in which you use the extended label.
Figure 18-14 shows an extended label (called A Special Label) added in the Application Settings dialog box, Session Options page. Figure 18-15 shows the text for the extended label for a specific entity entered in the Edit dialog box and then displayed on the screen.
Figure 18-14. Extended label added to session
Viewing Information about Objects — Using Extended Labels
Figure 18-15. Extended label text for a simulation object
You can display extended labels in Plan View mode the same as other symbol decora- tions. For more information, please see “Displaying Labels for 2D Icons,” on
page 18-14.
To add an extended label:
Choose Settings Application. The Application Settings dialog box opens.
Select the Session Options page (Figure 18-14).
Click the Add button ( ) on the Extended Labels line. A label is added to the list window. It has a generic name (for example, Label 1).
Double-click the label name to make it editable.
Type the name you want for this label.
Edit simulation objects to specify the text for this label.
To change an extended label’s index:
Choose Settings Application. The Application Settings dialog box opens.
Click the up or down arrow next to a label’s index number. The index number changes and, if applicable, the label moves up or down in the list.
To delete an extended label:
Choose Settings Application. The Application Settings dialog box opens.
In the Extended Labels window, select the label you want to delete.
Click the Delete button ( ).
The 2D Icons model set uses MIL-STD 2525B icons. Figure 18-16 illustrates basic icon shapes for friendly forces.
Tracked Dismounted infantry Fixed-wing Rotary-wing Surface Subsurface
Figure 18-16. MILSTD-2525B icons
The color and shape code for 2D simulation object icons is:
Light blue – friendly.
Salmon – hostile.
Symbols have a black border except as follows:
If there is no border on the top, the entity domain is subsurface, for example, submarines.
Selected simulation objects have a white border.
Symbols that represent units have unit identifiers above the symbol, as illustrated in Figure 18-17.
Circle with slash = Team or crew One dot = Squad
Two dots = Section
Three dots = Platoon or Detachment 
One bar = Company
Figure 18-17. Unit echelon indicators
Viewing Information about Objects — Simulation Object Icons
The Plan View observer mode uses the 2D Icons model set for simulation objects. You can change the size of 2D icons. When many simulation objects are close together, reducing the size of the icons can reduce overlap.
To change the size of simulation object icons:
Choose Settings Display. The Display Settings dialog box opens.
Select the Entity Display Settings page (Figure 18-18).
Adjust the Simulation Object Icon Scale slider.
You can also change the size of 2D icons from the Display Settings Toolbar.
To change the size of simulation object icons from the Display Settings toolbar:
On the Display Settings Toolbar, click the Icon Scaling button 
). The Simula- tion Object Icon Scale Factor slider opens.
Adjust the slider to change the size of the icons.
The Simulation Object Icon Scale Factor slider is a dockable widget that you can undock and leave visible as long as icon scaling is enabled.
By default, when a simulation object’s heading changes, the heading indicator points to the new heading, but the icon remains oriented towards zero degrees (North). You can specify that icons rotate to the heading of the simulation object.
Figure 18-19. 2D icon rotated to heading
To rotate icons to a simulation object’s heading:
Choose Settings Display. The Display Settings dialog box opens.
Select the Rotate Entity Military Standard Symbols to Heading check box.
Viewing Information about Objects — Displaying HAT Lines for Entities (3D Only)
Height-above-terrain (HAT) lines are vertical lines that run from an entity to the ground and display the altitude of the entity (using whatever units are configured on the Display Units Settings page) (Figure 18-20). They help you understand the rela- tionship of the entity to the terrain.
HAT lines are shown only for entities that could be above or below the ground, such as fixed and rotary-wing vehicles. You can show and hide these lines globally and you can specify that they be shown only for the selected entities.
When you create or edit an entity, VR-Forces displays HAT lines even if they are other- wise disabled.
Figure 18-20. Entity height-above-terrain lines
! Displaying height above terrain lines can reduce the frame rate.
To show or hide height-above-terrain lines:
Choose Settings Display. The Display Settings dialog box opens.
To display lines, select the Enable Height Above Terrain Lines check box.
To display lines only for selected entities, select the Only Display Height Above Terrain Lines For Selected Entities check box.
You can also enable and disable entity HAT lines by choosing Settings Entity Height Above Terrain Lines or by clicking the Entity Height Above Terrain Lines button 
) on the Display Settings Toolbar.
You can display a simulation object’s threat range – the area within which its armaments are effective. The threat range is displayed as a circle, with a line indicating the arma- ment and its direction of fire (Figure 18-21). A ring is displayed for each weapon system that the entity has. For example, in Figure 18-21, the M1A2 entity has an inner ring for its 62mm machine gun and an outer ring for its 120mm main gun.
You can also display range rings for a simulation object’s sensors (Figure 18-22).
2D 3D
Figure 18-21. Range rings (entity-level scenario)
Simulation objects in aggregate-level scenarios display range rings that show their combat effectiveness and a footprint that represents the physical area that the unit occu- pies (Figure 18-22). Unit range rings have breaks to show the front, rear, left flank, and right flank sectors.
Footprint (green) Weapon (red) Sensor (blue)
Figure 18-22. Range rings (aggregate-level scenario)
Figure 18-23. Range ring sphere
On small databases, a simulation object’s range ring may extend beyond the edge of the terrain display.
To enable or disable the display of range rings:
To pin range rings for a simulation object:
Enable range rings, as described in “Enabling and Disabling the Display of Range Rings,” on page 18-26.
Select a simulation object.
Choose Objects Pin Range Rings.
You can configure the color of range rings and their transparency by weapon type and sensor type. You can also configure the display of range ring labels (Figure 18-24). A label can display the entity name, weapon type, and range of the weapon.
Figure 18-24. Range ring labels
To configure the display of range rings:
Choose Settings Display. The Display Settings dialog box opens.
To display a sphere in 3D views, select the Show Range Sphere in 3D Using Opacity Modifier check box. Optionally, change the opacity modifier value.
To display the type of sensor or weapon system, select the Show Weapon Name check box.
To display the name of the simulation object, select the Show Entity Name check box.
To show the range of the sensor or weapon system, select the Show Range Value check box.
To automatically display range rings when a simulation object is created or discov- ered on the network, select Display Range Rings by Default.
If this setting is selected, when you load a scenario, range rings are displayed for all simulation objects.
To display range rings for a selected simulation object that has not enabled range rings, select Display Range Rings for Selected.
Figure 18-25. Range Rings Settings page (AggregateLevel.sms)
To always show the footprint of a simulation object, select Always Display Foot- print.
To enable or disable display of range rings for a particular weapon system, select or clear the check box for that system.
To change the color used to display a range ring:
For the type of weapon system or sensor whose color you want to change, select User-Defined Color in the Color column list. The color swatch next to the list changes.
Click the color swatch. A color picker dialog box opens.
Select the color you want to use.
Click OK.
To change the opacity for a range ring, for the weapon system whose range ring opacity you want to change, change the value in the Opacity column.
Viewing Information about Objects — Displaying Entity Resources
VR-Forces tracks the amount of resources that a simulation object has. You can view the status of resources in the Information dialog box.
Figure 18-26. Resource Information page
To view a simulation object’s resource status, on the Information dialog box, select the Resources page.
Viewing Information about Objects — Displaying Bounding Volumes
You can display bounding volumes for simulation objects. Bounding volumes show the area around a simulation object that the back-end uses for intersection calculations.
Bounding volumes are shown as translucent volumes in 3D and translucent rectangles in 2D (Figure 18-27). For simulation objects in aggregate-level scenarios, the bounding volume is equivalent to the footprint.
2D 3D
Aggregate-level bounding volumes
Figure 18-27. Bounding volumes
To enable or disable bounding volumes:
Choose Settings Display. The Display Settings dialog box opens.
Select the observer mode for which you want to enable or disable bounding volumes.
Select or clear the Bounding Volume check box.
You can configure VR-Forces so that it shows bounding volumes only for selected simu- lation objects.
To display bounding volumes only for selected simulation objects:
Choose Settings Display. The Display Settings dialog box opens.
Select the observer mode for which you want to enable bounding volumes.
Select the Bounding Volume check box.
Select the Show Bounding Volumes for Selected Entities check box.
The Information dialog boxes for simulation objects and tactical graphics have a console that displays messages sent from the simulation engine, from a simulation object’s plan, from other simulation objects, and from scripts. You can set the notifica- tion level that controls the display of these messages. You can save them to the clip- board, and you can clear the display. These messages are also sent to the Object Console Summary Panel.
Scripted tasks can ask questions. You can answer these questions from the Object Console Summary Panel.
Console messages are displayed only if they match or exceed the notification level set for that object. The notification level is set individually for each object. You can set the notification level in the object’s Information dialog box, with the Notify Level set data request (for simulation objects), or with the objectConsoleNotifyLevel parameter in vrfSim.mtl. (For the set data request procedure, please see “Notify Level,” on
page 34-28.)
To set the notification level for an object’s console in the Information dialog box:
Select the simulation object.
Choose Objects Information. The Information dialog box opens.
Expand the Object Console section (Figure 18-28).
Select a notification level from the Notify Level list.
You can view all object console messages in one place – the Object Console Summary Panel. Messages are displayed based on the notification levels of the individual simula- tion objects in the scenario. You can set the notification level in a simulation object’s Information dialog box or using the Notify Level set data request.
When VR-Forces sends a message to a simulation object’s console, it displays an excla- mation point next to the entity until you view the message (unless you disable this feature). The messages in the Object Console Summary Panel also display an exclama- tion point until you open the Information dialog box for that entity or click Acknowl- edge All.
Figure 18-29. Object Console Summary Panel
To display the Object Console Summary panel, choose View Object Console Summary Panel.
To remove the exclamation point from messages in the Object Console Summary Panel, click Acknowledge All.
Scripted tasks can send questions to the object console. Questions are indicated by a question mark next to the message (Figure 18-30). The script will offer a set of responses as buttons, option buttons, or a list. You can answer questions from the Object Console and the Object Console Summary Panel.
Figure 18-30. Question in console
To answer a question from a scripted task:
On the Object Console or Object Console Summary Panel, click Answer Ques- tions. A dialog box with the possible answers is displayed.
Choose an option.
Click OK.
To save console messages to the clipboard:
Select the simulation object.
Choose Objects Information. The Information dialog box opens (Figure 18-28).
If the Object Console is collapsed, expand it.
To save all messages in the console, click Copy to Clipboard. To save specific messages, select them and click Copy to Clipboard.
Paste the text into the text editor or word processor of your choice.
VR-Forces can display a notification icon when an object receives a message on its object console (Figure 18-31). This option is enabled by default, however the default notification level is Warn and objects do not typically get messages at this level. The more likely use for this icon is to set the notification level to Info or lower and then check the console when a notification is received. For details about how to set the noti- fication level, please see “Setting the Notification Level for Console Messages,” on page 18-32.
Figure 18-31. Object console warning icon
The icon is not displayed if the Information dialog box is open. If an icon is displayed for an object, when you open its Information dialog box, the icon is removed.
To enable or disable the console warning icon:
Choose Settings Display. The Display Settings dialog box opens.
Select or clear the Show Object Console Warning Icon check box.
To clear the messages from the object console, click Clear.
Viewing Information about Objects — Viewing Object Counts
To display the object counts, choose View Objects Count Panel. The Objects Count Panel is added to the display (Figure 18-32).
Figure 18-32. Objects Count Panel
19. Creating Simulation Objects
This chapter explains how to create and manipulate simulation objects in general, and entities in particular. For information about working with units, please see Chapter 24, Creating and Controlling Units.
Creating Simulation Objects 19-3
Default Placement of New Entities 19-3
Placing Entities Inside Buildings 19-4
Placing Simulation Objects on Other Simulation Objects 19-4
Simulation Object Resources 19-4
Deleting Simulation Objects 19-5
Editing Simulation Objects 19-5
Embarking and Disembarking Simulation Objects 19-7
Embarking and Disembarking Simulation Objects Instantly 19-8
Disembarking Simulation Objects Using the Disembark Command.. 19-11 Embedded Entities 19-12
Configuring an Entity to Support Embedded Entities 19-13
Assigning Tasks and Plans to Embedded Entities 19-15
Restoring an Entity that has Embedded Entities 19-15
Collision, Obstacle, and Feature Avoidance 19-16
Entity Movement and Soil Type 19-17
Using a Joystick to Control Entities 19-18
Switching Between Systems 19-19
Disabling Joystick Control 19-20
Using the Keyboard to Control an Entity 19-20
Configuring Ground Clamping 19-22
Creating Simulation Objects
Exaggerating the Scale of 3D Entity Models 19-23
Creating Simulation Objects — Creating Simulation Objects
The basic procedure for creating a simulation object is fairly simple:
On the Create menu or Simulation Objects Palette, select the simulation object that you want to create.
Click on the terrain to place the simulation object.
Optionally, specify the properties of the simulation object, such as name, altitude, and heading.
The generic procedures for choosing the simulation object to create, placing it on the terrain, and setting properties are described in Chapter 16, Creating and Placing Objects. This section provides additional details about simulation object creation and place- ment.
You can also create simulation objects by copying existing simulation objects. For details, please see “Copying and Pasting Objects,” on page 16-21.
You can create preconfigured units the same way you create individual entities. You can also create units by aggregating simulation objects. To learn how to create a unit, please see “Creating Units,” on page 24-2.
!
!
When you create simulation objects, if spot reports are enabled and a particular force is hidden, if you create a simulation object of the hidden force, you will not be able to see it. It is recommended that you disable spot reports or set the viewpoint to show all forces when you are creating scenarios. For details about spot reports, please see “Displaying Simulation Objects Based on Spot Reports,” on page 9-2.
Ground-based entities are placed at the highest possible terrain intersection at the loca- tion. If a terrain supports buildings with multiple levels, the entity is placed at the highest level. Once the entity begins moving, if the next calculated location resides in- between two levels of terrain, and if the entity is configured to respect terrain intersec- tions when moving, and there is no terrain blocking its movement, the entity places itself at the closest elevation to the desired location.
Creating Simulation Objects — Creating Simulation Objects
One of the benefits of creating entities in a 3D observer mode is the ease of placing them in the precise location and orientation that you want them to be in, particularly inside buildings. However, placing entities inside small enclosed spaces can be hindered by the location of walls relative to the observer. You can work around this problem by:
Adjusting the near clipping plane to remove the display of walls and floors until you see the location where you want to place entities. For details about changing the clipping plane, please see “Setting the Clipping Planes,” on page 77-9.
Adjusting the transparency of a building so that you can see inside of it. For details about changing transparency, please see “Setting the Opacity of Props,” on
If you want to place a simulation object on or in another simulation object, such as an aircraft on an aircraft carrier or a dismounted infantry entity in a truck, then you must embark the simulation object. Creating a simulation object on top of another simula- tion object will not provide the results you want. For example, if you create a fixed-wing entity and manipulate its location and altitude so that it looks like it is on the deck of an aircraft carrier, as soon as you start the simulation, the jet will start flying at that alti- tude, because it is not attached to the carrier. It is just created at a particular location. For complete details about embarking simulation objects, please see “Embarking and Disembarking Simulation Objects,” on page 19-7.
When you create a simulation object, it has a full complement of resources, as defined in the object parameter database. You do not have to assign resources to a simulation object when you create it. However, if you want a simulation object to start a simula- tion with less than a full set of resources, you can use the Resource set data request to set its resources at some amount less than 100%.
Creating Simulation Objects — Editing Simulation Objects
To delete a simulation object:
Select the object you want to delete.
Choose Objects Delete or press the Delete key.
i If you delete a unit, all its subordinates also get deleted.
If you delete a simulation object that has an intervisibility object pinned
to it, the intervisibility object also gets deleted. For details, please see “Deleting Intervisibility Objects,” on page 46-12.
You can edit the following simulation object properties:
Name.
Label (and extended labels if available).
Force.
Location.
Heading.
Altitude.
Overlay.
Creating Simulation Objects — Editing Simulation Objects
Select the simulation object.
Choose Objects Edit. The Edit Entity dialog box opens (Figure 19-1).
Change the properties as desired.
Click OK.
You can also change the location, altitude, and heading dynamically, through a variety of movement tasks, or with set data requests. For details, please see:
Embarkation places simulation objects into or onto other simulation objects, for example, dismounted infantry in a truck, trucks on an LCAC, or aircraft on an aircraft carrier. While embarked, the simulation objects travel with the simulation object on which they are embarked. Embarked simulation objects are not visible in the 2D view. They are always visible in the 3D view.
Embarked entities can shoot while they are embarked if they are embarked on an entity that has object geometry enabled.
!
!
If you are using HLA and want to use the embarkation feature, you must use RPR FOM 2, draft 17 or later. VR-Forces includes configurations in the Simulation Connections Configuration dialog box that start VR-Forces using the correct FED file and FOM Mapper for RPR FOM 1.0 and RPR FOM 2.
Attached objects are shown in the Embarkation View on the Objects List Panel.
The embarkation status of simulation objects is displayed in the Embarkation View of the Objects List Panel (Figure 19-2).
You can embark and disembark simulation objects instantly (described in this section), or you can have them simulate embarkation and disembarkation using the Embark and Disembark tasks, described in Chapter 30, Embarkation, Wait, Radio, and Other Tasks.
Embarked entities controlled by joystick cannot disembark. For example, if you use a joystick to control a fixed-wing taking off from a carrier, the aircraft will take off, but it will remain in an embarked state.
You can embark and disembark simulation objects instantly in the following ways:
Using the Embark On command.
In the Embarkation View.
Using automatic embarkation.
Using set data requests lets you include immediate embarkation in plans. This may be particularly useful in a global plan, in which you may want to quickly create and embark simulation objects without paying attention to the realism of the action. For details about using set data requests for embarkation, please see “Embarked,” on
page 34-17 and “Disembarked,” on page 34-17.
The Embark On command lets you embark simulation objects using preconfigured embarkation spaces or using specific coordinates. If the embarkation spaces on the parent simulation object are full, VR-Forces sends a message to the back-end console and the simulation object is not embarked. To embark simulation objects instantly from a plan, use the Embarked set data request.
To embark a simulation object instantly using the Embark On command:
Choose Objects Embark On. The Embark On dialog box opens.
Figure 19-3. Embark On dialog box
Optionally, filter the list of potential parent simulation objects.
Select the parent simulation object.
To embark in a configured space, select the Reserve Slot option. To specify an embarkation point, select Override Position.
If you chose the Override Position option, specify the coordinates on the parent, in body coordinates, for the embarkation point.
Click OK.
To embark an object in the Embarkation View:
On the Objects List Panel, select the Embarkation View.
Drag the simulation object you want to embark onto the parent simulation object. The Embarked dialog box opens.
To specify an embarkation location, specify X, Y, and Z values. If you do not specify a location, the simulation object gets embarked at the center of the parent simulation object.
Click OK.
Automatic embarkation lets you embark simulation objects as you create them. It has the following conditions:
It is only available in 3D observer modes.
The simulation object you want to embark must be capable of embarking (as configured in the OPD).
The simulation object you want to embark on must allow embarkation.
There is no option to override embarkation slots by specifying a particular location.
If slots are configured on the parent simulation object and you select the option to use slots, embarked simulation objects are placed in slots until the slots run out. Then they are placed on the parent simulation object where you click.
You can attach tactical graphics to simulation objects using this method. For more information, please see “Attaching a Tactical Graphic Automatically,” on page 39-11.
To embark a simulation object using automatic embarkation:
Create the entity on which you want to embark another entity (if it is not already created.)
In the Simulation Objects Palette, select the entity that you want to embark.
Optionally, configure auto-embarkation, as follows:
If the Create Entity dialog box is not open, click its tab to open it.
To enable or disable automatic embarkation, select or clear the Enable Auto- matic Embarkation check box.
To embark the entity in a slot if one is available, select the Embark in Slot if Available check box.
Move the cursor over the entity you want the new entity to embark on. If it supports embarkation and automatic embarkation is enabled, a green box is displayed. (If the entity does not support automatic embarkation, no green box is displayed.) If the create dialog box is open, the Not Embarked label changes to Embark On entity_name.
Click to place the entity.
Embarked entities controlled by joystick cannot disembark. For example, if you use a joystick to control a fixed-wing taking off from a carrier, the aircraft will take off, but it will remain in an embarked state.
To disembark a simulation object instantly:
Select the simulation object that you want to disembark.
Choose Objects Disembark. If the simulation object was embarked using the default embarkation point, it is disembarked next to the former parent simulation object. If the simulation object was embarked using a position override, it is disem- barked in the same location as the former parent.
To disembark a simulation object in the Embarkation View:
Open the Embarkation View.
Drag the simulation object you want to disembark from the parent simulation object to the force level.
To disembark all simulation objects from a parent entity:
Select the parent simulation object.
Choose Objects Disembark All.
Embedded entities are a convenient way to manage entities that are typically embarked on other entities.
The embedded entity feature lets you configure entities with a set of embedded entities. You can then deploy the embedded entities and give them tasks or plans. Once deployed, there is no difference between an embedded entity and any other entity, except that a parent entity can recover a deployed entity. You do not need to manage the initial process of creating the relationship between the entities via embarkation and disembarkation.
For details about deploying and recovering embedded entities, please see “Embedded Entity Tasks,” on page 30-14.
Embedded entities are configured in systems, which you then add to an entity in the Simulation Object Editor. An entity can have only one embedded entity system. There- fore, if you need different configurations of embedded entities for different parent enti- ties, you must create a system for each configuration.
Within a configuration, you must specify each embedded entity. In other words, you cannot specify a system as containing, for example, 5 helicopters and 40 F/A-18 jets. In this case the system would have to individually specify each helicopter and each jet.
A system definition file for embedded entities specifies the entities and the metadata needed to edit properties in the Simulation Object Editor. You must give each entity a unique name.
An entity is formatted as follows (from ./data/simulationModelSets/EntityLevel/vrfSim/ systems/other/ddg-embedded-support-craft.sysdef):
(embedded-entities (ee-1
(entity-name "SH-60 Seahawk Alpha") (entity-type 1 (1 2 225 22 3 1 0))
(deployment-time 0.0)
(recovery-distance 35.0)
(relative-position $rel-pos-lamps-a) (relative-heading $rel-heading-lamps-a)
)
...
(ee-2
(entity-name "RHIB Alpha")
(entity-type 1 (1 3 225 63 8 0 0))
(deployment-time 15)
(recovery-distance 50.0)
(relative-position $rel-pos-rhib-a) (relative-heading $rel-heading-rhib-a)
)
...
)
The relative-position and relative-heading parameters are variables that link to the meta- data, as follows:
(parameter-data-list (vector-parameter-data
(parameter-name "rel-pos-lamps-a") (variable-type "DtRwVector")
(display-label "Seahawk Alpha's relative position") (display-units "meters")
(source-units "meters")
(default-value -75.000000 0.000000 -6.500000)
(relative-to "")
)
(vector-parameter-data
(parameter-name "rel-pos-rhib-a") (variable-type "DtRwVector")
(display-label "Rigid-hull Alpha’s relative position") (display-units "meters")
(source-units "meters")
(default-value -75.000000 10.000000 -6.500000)
(relative-to "")
)
...
(real-parameter-data
(parameter-name "rel-heading-lamps-a") (variable-type "DtRwReal")
(display-label "Seahawk Alpha's relative heading") (display-units "degrees")
(source-units "degrees") (default-value 0.000000)
)
(real-parameter-data
(parameter-name "rel-heading-rhib-a") (variable-type "DtRwReal")
(display-label "Rigid-hull Alpha’s relative heading") (display-units "degrees")
(source-units "degrees") (default-value 90.000000)
)
...
)
Figure 19-4 illustrates the properties dialog box created for the system shown in the previous paragraphs.
Figure 19-4. Embedded Entity Properties dialog box
Once an embedded entity is deployed, it is just like any other entity in the scenario. You can give it independent tasks or write a plan for it. Follow the standard procedures for these activities.
If you deploy an embedded entity and it gets destroyed, it is removed from the scenario and is not available to be deployed again. However, if you restore a parent entity and it had deployed entities that were subsequently destroyed, it is restored to the full comple- ment of embedded entities. Entities that are deployed at the time the parent is restored are not affected. They are not duplicated in the parent’s inventory and their relationship is not affected.
Creating Simulation Objects — Collision, Obstacle, and Feature Avoidance
By default, in entity-level scenarios, simulation objects avoid other simulation objects, features, and obstacle control objects. If, while carrying out a task, a ground, lifeform, or rotary-wing entity detects that it is on course to collide with another entity, a feature, or an obstacle, it alters its route to avoid the collision. Then it returns to its task.
In entity-level scenarios, aggregated units do not avoid obstacles and collisions. When disaggregated units move, the individual members of the units use collision avoidance.
In aggregate-level scenarios, there is no collision avoidance between simulation objects. If a unit encounters an obstacle, it stops, sends a message to the console, and awaits further instructions.
When an entity avoids an obstacle, it does not necessarily follow the outline of the obstacle, it avoids the obstacle's bounding volume, which is conceptually the smallest rectangle that bounds all of the points in the obstacle.
Ground entities avoid features, such as buildings and plants. By default, entities avoid other entities (some cultural features are created as entities), buildings, water, and vege- tation. (LCACs do not avoid vegetation by default.)
Collision avoidance has the following qualifications:
To specify that ground entities should not move through the terrain (for example, through a wall or through a hill), set the check-terrain-collisions parameter in the automotive actuator component (powertrain) to True. For performance reasons, it defaults to False, so that entities that do not care about terrain collisions do not perform the check.
If an entity is tasked to move to a point that is inside an obstruction, or very close to one, it might never reach the point, but it will continue to try to reach the point as long as the task is in effect. This behavior also applies to entities following routes that have vertices inside an obstruction.
If a terrain has geometric features as well as point vector features, the feature avoid- ance may not work because the points are placed on the terrain on “top” of the existing geometry, which means they are on top of the geometric feature.
Do not place entities inside obstacles. Their behavior will be unpredictable.
Although you can assign a force to an obstacle when you create it, it has no effect on entity behavior. Entities avoid all obstacles.
You can configure the objects that an entity will avoid by editing its entry in the object parameter database. For details about configuring obstacle avoidance, please see “Configuring Obstruction Avoidance,” on page 73-4.
Creating Simulation Objects — Entity Movement and Soil Type
In VR-Forces, the movement of simulation objects is affected by the surfaces on which they are moving. The speed of movement over a given surface (as a percentage of ordered speed) is configured in the soil-list block in a simulation object’s object param- eter database entry.
Table 19-1 lists the soil types supported for terrain databases and how they map to the roughness types that can configured in the soil-list block for VR-Forces simulation objects.
Table 19-1: Soil type/roughness type mappings
Soil type Roughness type
Soil type Roughness type
ocean deep-water
deepLake deep-water
shallowLake shallow-water
deepRiver deep-water
shallowRiver shallow-water
shallowPond shallow-water shallowStream shallow-water dryGround hard-packed
pavedRoad paved-road
gravelRoad gravel
dirtRoad gravel
asphalt hard-packed
USRailroad hard-packed
softSoil sand
swamp muck
mud muck
forest hard-packed
grass hard-packed cultivatedFields hard-packed orchards hard-packed
rock rocks
boulder rocks
sand sand
building hard-packed
tree hard-packed
Creating Simulation Objects — Using a Joystick to Control Entities
VR-Forces supports use of joysticks, other types of game controllers, and keyboard keys to control ground, fixed-wing, and rotary-wing entities. You can attach multiple joysticks, which allows you to control multiple entities, movement and weapons fire on one entity, or some combination. You can also use a joystick and keyboard mappings together to control an entity.
Joystick control is managed in the front-end. Joysticks should be attached to the computer from which you are running the front-end. Control messages are sent to the back-end, which can be on any computer in the simulation.
Red Hat 6 does not support joysticks by default, but it can be enabled in the operating system. For details, go to this web site: https://access.redhat.com/solutions/64114
You cannot enable or disable joystick support for all entities at once. You can only enable joysticks for individual entities.
Embarked entities controlled by joystick cannot disembark. For example, if you use a joystick to control a fixed-wing taking off from a carrier, the aircraft will take off, but it will remain in an embarked state.
For information about how to configure joysticks, please see “Config- uring Joysticks and Keyboard Control,” on page 75-2.
To enable joystick control:
Select the entity for which you want to enable joysticks.
Choose Objects Take Control. The Take Control dialog box opens.
Figure 19-5. Take Control dialog box
Select a joystick configuration from the Configuration list. (If you have specified a joystick configuration as a favorite, you do not have a choice of the configuration to use.)
Select the entity functions you want to control, usually movement and one or more weapons. (You can have more than one joystick attached and can also use keyboard controls, if they are configured.)
Click OK.
Creating Simulation Objects — Using a Joystick to Control Entities
Systems that are controlled by joysticks can be organized into functional groups so that you can configure them similarly and switch between the systems using a “switch between” key or button. VR-Forces includes a switch group for weapons. If an entity has multiple weapon systems, you can manage them in the following ways:
Configure all weapons to use the same keys or joystick controls for the same func- tion. For example, to fire any weapon, you could press f. Use the switch between key to switch between weapons for a given entity. You only need to learn one set of controls to manage all your weapons.
Configure all weapons to use different keys or joystick controls for the same func- tions. For example, to fire a 120mm gun, press f; to fire a 7.62mm gun, press g. You would not use the switch between option.
If an entity has multiple weapons and you use switch options to change which one you control, there no visual cue in the GUI to show you which weapon you are currently controlling. If there are more than two weapons on an entity, the switch option cycles through them.
You can create your own switch groups. For details, please see “Configuring “Switch Between” Options,” on page 75-10.
If an entity has more than one instance of the same system, you must change the name of the function group if you want to control them separately. For example, suppose you want to mount two chain guns on an Apache helicopter. If they both have the same function group name (weapon:M230 Ballistic Gun), then you could not switch between them. You would need to rename one of them. This is done in the Simulation Object Editor when you add the additional system. (For complete details about using the Simulation Object Editor, please see Chapter 64, The Simulation Object Editor and SMSs and Chapter 65, Editing Simulation Object Models.)
To rename a system function group:
On the Start menu, choose MÄK Technologies VR-Forces 4.5 Tools Simula- tion Object Editor. The Simulation Object Editor opens.
Load EntityLevel.sms.
Select the entity whose system you want to edit.
In the systems list, for example the Weapons list, select the system you want to edit.
Click the Properties button for the system. A Properties dialog box opens.
Edit the function group name. For example, change weapon:M230 Ballistic Gun to weapon:M230 Ballistic Gun 1.
Click OK.
Save the SMS.
Creating Simulation Objects — Using the Keyboard to Control an Entity
To disable joystick control:
Choose Objects Release Control.
The joystick configuration process allows you to configure keyboard control of entity movement and weapons. You can use keyboard control along with joysticks. For example, you could control entity movement from the keyboard and weapons from a joystick, or the opposite.
To enable or disable keyboard control, follow the procedures for enabling and disabling joystick control. Similarly, to configure keyboard control, follow the joystick configura- tion process. For more information, please see “Using a Joystick to Control Entities,” on page 19-18 and “Configuring Joysticks and Keyboard Control,” on page 75-2.
Because of differences in terrain databases among exercise participants, entities can sometimes appear to be underground or hovering above the terrain surface. To compensate, VR-Forces can clamp land and sea entities to the terrain surface. When ground clamping is enabled, VR-Forces keeps an entity anchored to the terrain surface regardless of the altitude data contained in its state update.
Use of ground clamping can reduce your frame rate. If you correlate the simulation and visualization terrain databases, you can eliminate the need to use ground clamping.
Although ground clamping controls are available in aggregate-level scenarios, since aggregate-level scenarios do not use 3D models, they are not useful.
Creating Simulation Objects — Using Ground Clamping
To enable or disable ground clamping:
Choose Settings Display. The Display Settings dialog box opens.
Select the Entity Display Settings page (Figure 19-6).
Select or clear the Enable Ground Clamping check box.
You can also enable and disable ground clamping by choosing Settings Ground Clamping, or clicking the Ground Clamping button ( ) on the Display Settings Toolbar.
Creating Simulation Objects — Using Ground Clamping
You can configure the following aspects of ground clamping:
Enable or disable orientation clamping.
Force lifeforms to remain upright relative to the plane of their location when moving up slopes or steps, rather than being perpendicular to the terrain.
The distance from the terrain within which entities are clamped.
To configure ground clamping:
Choose Settings Display. The Display Settings dialog box opens.
To enable or disable a ground clamping option, select or clear its check box.
The setting for the Ground Clamping Cutoff Distance Scale maximizes at 100 meters. If you set it to the maximum, the distance is infinite and all entities are ground-clamped.
If you view the terrain in Stealth observer mode, beyond a certain distance most 3D entity models are too small to see. Model scaling lets you exaggerate the scale of entity models to see them at a great distance. Figure 19-7 shows the same scene with model scaling off and on. When model scaling is off, only the largest entities are visible. When models are scaled, they are all visible.
VR-Forces supports the following types of model scaling:
XR scaling. XR scaling tries to give all entities approximately equal visibility. It does not preserve size relationships between entities. The visual effect of model scaling depends on an entity’s size and the observer’s distance from the entity. When the observer is close to an entity, scaling models may not make any noticeable differ- ence in its size.
Linear scaling. Linear scaling scales all entities by the current model scale factor. The distance from the observer is not taken into account. A model scale factor of 10 scales all entities to be 10 times normal size.
Figure 19-7. Model scaling off and on (Stealth observer mode)
Creating Simulation Objects — Exaggerating the Scale of 3D Entity Models
Another way to quickly change the visibility of entities is to switch to XR observer mode. In XR mode, entities are immediately scaled and are represented by colorized 3D models to enhance their visibility.
Figure 19-8. XR mode
To scale entity models:
Choose Observer Advanced Settings. The Display Settings dialog box opens to the Observer Settings page (Figure 19-9).
In the list of observer attributes, select Model Scaling.
In the Model Scaling Type list, select the type of scaling you want to use – XR or linear.
Optionally, change the Maximum Scale Factor.
Adjust the Scale Factor slider to the amount of scaling that you want.
Creating Simulation Objects — Hiding 3D Models
You can hide 3D models and 3D colorized models.
To hide 3D models:
Choose Settings Display. The Display Settings dialog box opens.
In the list of observer settings, clear the Main Model check box.
You can also change the color of a force in the Simulation Object Editor. For details, please see “Editing a Force,” on page 64-23.
To change force coloring:
Choose Settings Display. The Display Settings dialog box opens.
Select the Force Coloring Settings option that you want.
20. Generating Traffic (Pattern of Life)
This chapter explains how to automatically generate pattern of life simulation object traffic and how to create and task pedestrian crowds.
How Spawn Events are Scheduled 20-6
Spawning Entities in Bursts 20-8
Default Spawn Patterns and Scenario-Specific Patterns 20-9
Creating a Spawn Pattern 20-10
Deleting a Spawn Pattern 20-16
Generating Traffic (Pattern of Life) — Generating Traffic
The VR-Forces traffic feature (also called spawn and sink or pattern of life) lets you automatically generate background traffic for your scenario.
Automatically generated (spawned) simulation objects are created at spawn points. The default behavior for a spawned simulation object is to randomly choose a destination, called a sink point, and move towards that point. When it arrives at the sink point it is removed from the scenario. This creates the effect of
purposeful activity in an area of the terrain without the need to create and task simula- tion objects individually.
As an alternative to the default behavior, you can write a plan that is assigned to each simulation object created at a particular type of spawn point. This plan can include any tasks and set data requests that are appropriate for the object type.
The behavior of a spawned simulation object, as well as other details such as how frequently they are spawned and how many spawned simulation objects can exist at one time, is configured in a “spawn pattern”. VR-Forces comes with two spawn patterns to get you started. You can edit spawn patterns and create as many new ones as you wish. Spawn points and sink points for new and edited spawn patterns are dynamically added to the Create menu and Tactical Graphics Palette so that it is easy to create new spawn and sink points for all of the available patterns.
The SubwayPOL example scenario has spawn patterns that demonstrate continuous simulation object creation, burst traffic, and use of a custom plan. The release also includes video tutorials that show simple examples of spawn patterns.
Spawn and sink points are automatically added to the Create menu. However, they are not flagged as Favorites on the Tactical Graphics Palette. If you flag a spawn or sink point as a Favorite (by clicking the star next to the point’s name in the list of points) a duplicate entry is added to the Create menu.
You can create spawn points from the Create menu, the Tactical Graphics Palette, or from the Spawn Pattern Manager. Figure 20-1 illustrates a spawn point.
Generating Traffic (Pattern of Life) — Creating Spawn Points
If the plan for a spawn point specifies Use Roads and a spawn point is placed too far away from the road network to use roads, a message is sent to the spawn point’s console. If warning icons are enabled, a warning icon is displayed. For details about the Use Roads option, please see “Creating a Spawn Pattern,” on page 20-10. For details about configuring console messages and warning icons, please see “Configuring Object Console Messages,” on page 18-31.
To create a spawn point from the Create menu:
Choose Create Spawn Points type, where type is one of the spawn patterns. The cursor changes to the waypoint symbol.
Click on the terrain where you want to place the spawn point. You can continue clicking to create additional spawn points.
Right-click to exit create mode.
To create a spawn point from the Spawn Pattern Manager:
Choose Simulation Spawn Pattern Manager. The Spawn Pattern Manager opens (Figure 20-2).
Select the spawn pattern for which you want to create spawn points.
Click Create Spawn Points. The cursor changes to the waypoint symbol.
Click on the terrain where you want to place the spawn point. You can continue clicking to create additional spawn points.
Right-click to exit create mode.
Generating Traffic (Pattern of Life) — Creating Sink Points
If you are using the default spawned simulation object behavior – pick a sink point and move to it – then you have to create one or more sink points for the simulation objects to move to. Entities created at a given type of spawn point automatically choose among sink points of the same type. (You can configure spawned simulation objects to move to any kind of point by editing the spawn pattern. For details, please see “Creating a Spawn Pattern,” on page 20-10.) You can create sink points from the Create menu, the Tactical Graphics Palette, or from the Spawn Pattern Manager. Figure 20-3 illustrates a sink point.
If a sink point is more than 10 meters from a road and simulation objects move towards it with the Use Roads criteria, they move to the closest point on the road to the sink point and are then removed from the scenario.
To create a sink point from the Create menu:
Choose Create Sink Points type, where type is one of the spawn patterns. The cursor changes to the waypoint symbol.
Click on the terrain where you want to place the sink point. You can continue clicking to create additional sink points.
Right-click to exit create mode.
To create a sink point from the Spawn Pattern Manager:
Choose Simulation Spawn Pattern Manager. The Spawn Pattern Manager opens (Figure 20-2).
Select the spawn pattern for which you want to create sink points.
Click Create Sink Points. The cursor changes to the waypoint symbol.
Click on the terrain where you want to place the sink point. You can continue clicking to create additional sink points.
Right-click to exit create mode.
A spawn pattern configures the following aspects of spawned simulation object creation and behavior:
The name and description of the spawn pattern.
The timing of simulation object creation. Entities can be spawned continuously or in bursts.
The type of simulation object created.
The spawned simulation object’s plan. Entities can follow a default plan or a custom plan.
A scenario can have multiple spawn patterns and each spawn pattern can spawn one or more object types. Spawning multiple simulation object types in one pattern is useful when you want heterogeneous traffic. For example, in a stream of pedestrians you might want to include men, women, and children. In other cases you might want a specific simulation object type engaging in specific behaviors and would only spawn one simulation object type in that pattern.
If you use the default plan, you can configure simulation object movement, as follows:
Maximum and minimum speed. VR-Forces will randomly assign a speed between the maximum and minimum settings. It will not accept a speed that is greater than the maximum speed for the simulation object in the OPD file.
Use Roads. Enables or disables road-following behavior for vehicles. Road following behavior is described in “Collision, Obstacle, and Feature Avoidance,” on page 19-16 and “Entity Movement On Roads and Off Roads,” on page 26-22.
When you use the default plan, the Create Spawn Pattern dialog box lists the sink points that this pattern will use.
The SubwayPOL example scenario has spawn patterns that demonstrate spawning simulation objects continuously and in bursts. It also demonstrates use of a custom plan. The following sections describe these different ways to set up spawn patterns.
Spawn patterns control the time period during which simulation objects are spawned and the rate at which they are spawned during that time period. A spawn pattern can use one of the following options:
Continuously. Entities are spawned as soon as the scenario starts and throughout its life.
Time of Day. Entities are spawned between a starting time of day and ending time of day.
Simulation Time. Entities are spawned between a specific starting and ending simulation time.
Figure 20-4 illustrates the difference between continuous and timed spawning.
Scenario start
Start time
End time
Continuous 
Timed 
Figure 20-4. Continuous spawning compared to time-based
Figure 20-5 illustrates a series of spawn events with a spawn interval of 10 seconds and a spawn interval variance of 0% and a series of hypothetical events with a spawn interval of 10 seconds and a spawn interval variance of 40%. In the second case, each spawn event can take place anywhere between 6 and 14 seconds after the previous event. Notice that a new spawn interval starts at each spawn event.
Spawn event
Spawn Interval
Spawn Interval = 10 seconds Variance = 0
Spawn event 
Period = 10 seconds Variance = 40% Range = 6 - 14 sec.
Figure 20-5. Spawn period and variance
The frequency with which a spawn point spawns simulation objects can be affected by the total number of simulation objects that it has spawned. If the maximum number of simultaneous simulation objects for a spawn point is reached, no more simulation objects are spawned from that point until simulation objects from that spawn point are removed from the scenario.
You can introduce additional variation to the spawn frequency by specifying that simulation objects be spawned in bursts. A burst pattern controls spawning behavior within a fixed period of time. For example, you could use a burst pattern to represent a cycle of train disembarkations or rush hour traffic.
Burst patterns have the following parameters:
Burst Period. The period of time during which a burst can take place.
Burst Length. The percentage of the burst period in which to spawn simulation objects.
Offset Start Time. An offset from the start of the burst period at which to start spawning simulation objects.
Within a burst, simulation objects are created at the rate determined by the spawn interval and spawn interval variance values.
Figure 20-6 illustrates a series of bursts. The burst period is 10 minutes. The offset start time is two minutes, so each burst starts two minutes after the start of the burst period. The burst lasts for 40% of the length of the burst period, in this case four minutes.
Burst Period = 10 minutes
Spawn event
Offset Start Time = 2 minutes Burst Length = 40%
As noted in “Generating Traffic,” on page 20-2, the default behavior for a spawned simulation object is to choose a sink point, move to the sink point, and be removed from the scenario. However, you can introduce more complex
behaviors for spawned simulation objects by writing a custom plan for a spawn pattern. By creating a custom plan, the simulation objects can engage in a complex set of behav- iors, but you still have the benefit of automatic generation. An example of using a custom plan would be to generate a steady stream of jets taxiing to a runway and taking off from an airport.
The VR-Forces includes default spawn patterns for civilian vehicles and civilian life- forms. When you create a scenario, these patterns are added to the scenario. When you save a scenario, the spawn patterns get saved with the scenario in the scenario extras file (.xtr). (This includes the default spawn patterns if you do not edit them, the edited versions if you have edited them, and any new spawn patterns you have created.) They are now scenario-specific. The next time you load the scenario, it uses the spawn patterns in the scenario extras file, not the default spawn patterns.
If you want to have additional default spawn patterns for your scenarios, you can add entries to ./appData/settings/vrfSim/defaultSpawnTemplates.mtl. Copy one of the patterns in the file, then change the name and parameter values to suit your needs. Or, create a spawn pattern in a scenario and copy it from the .xtr file to defaultSpawnTemplates.mtl.
Previous sections have explained the various components of a spawn pattern. This section explains how to create one.
To create a spawn pattern:
Choose Simulation Spawn Pattern Manager. The Spawn Pattern Manager opens (Figure 20-2).
Click New Pattern. The Create Spawn Pattern dialog box opens (Figure 20-7).
In the Name box, type a name for the spawn pattern. This name is used for the label for spawn points and sink points created from this pattern. This is a required field.
For example, if the maximum number of simultaneous simulation objects for a spawn pattern is 200 and you have 10 spawn points of that type, you could have as many as 2000 spawned simulation objects. None of the spawn points will spawn more than 200 simulation objects at one time.
!
!
A high maximum number of simultaneous simulation objects along with a small spawn interval can quickly generate tens to hundreds of simulation objects. This may affect performance.
Specify the simulation object types to create:
Click the Add button. The Entity Type dialog box opens. This dialog box lists simulation objects by category.
Select the category for the simulation object type you want to add.
Select the simulation object type that you want to add. The simulation object is added to the Type of Entity to Create list.
Add additional simulation object types as desired.
The Entity Type dialog box lets you specify all types of simulation objects, cultural features, and control objects, some of which do not necessarily make any sense to spawn. It is up to you to select types of simulation objects that make sense.
Choose an option in the Spawn Timing group box, as follows:
Spawn Continuously. Entities are spawned throughout the simulation.
Spawn Based on Time of Day. Specify the starting time of day and ending time of day during which you want simulation objects to be spawned.
Spawn Based on Simulation Time. Specify the starting simulation time and ending simulation time during which you want simulation objects to be spawned.
Optionally, select Spawn Entities in Periodic Bursts. (For an explanation of peri- odic bursts, please see “Spawning Entities in Bursts,” on page 20-8.) If selected, configure as follows:
Burst Length. The length of time, as a percentage of the burst period, during which simulation objects are spawned.
Specify the spawn interval variance as a percentage of the spawn interval.
In the Spawn Behavior group box, select a behavior option as follows:
– Use Custom Plan:
Click Edit Plan. The Edit Custom Plan dialog box opens.
Figure 20-8. Edit Custom Plan dialog box
Optionally, select the Specify Speed check box and specify the minimum and maximum speeds for spawned simulation objects. If you do not select this option, spawned simulation objects move at the default ordered speed in their OPD file. If you select it, they move at randomly chosen speeds between the minimum and maximum values. This option introduces some variance in behavior. Although the GUI allows you to set any maximum speed, simulation objects will not move faster than the maximum speed in the OPD file.
To have a simulation object move on roads, select the Use Roads check box. If this option is cleared, simulation objects move directly towards sink points without regard to vector road networks.
–
!
!
Use Roads is valid only for ground vehicles. Do not select this option for any other simulation object type.
If Use Roads is selected, spawn points must be within 10 meters of the road. If a spawn point is farther away, the simulation objects are removed from the scenario as soon as they are created.
If a sink point is more than 10 meters from a road, simulation objects that are moving towards that sink point move to the point on the road that is closest to it and are then removed from the scenario.
Optionally, use the Add button to edit the Sink Points list. A new spawn pattern will not have any sink points listed because until you create the spawn pattern, you cannot create any sink points for that pattern. Entities will auto- matically use sink points that match the spawn pattern, so after you create them, you do not have to add them to the list. However, they can also move to waypoints. If you want spawned simulation objects to move to waypoints, you must add them to the list.
Click Create.
If you want to create a new spawn pattern that will be similar to an existing spawn pattern, you can copy the existing spawn pattern to a new name.
To copy a spawn pattern:
Choose Simulation Spawn Pattern Manager. The Spawn Pattern Manager opens (Figure 20-2).
Click Copy Pattern. The Create Spawn Pattern dialog box opens. It has a default name based on the original pattern name.
Edit the spawn pattern. The meaning of each option is described in “Creating a Spawn Pattern,” on page 20-10.
Click Create.
Generating Traffic (Pattern of Life) — Editing a Spawn Pattern
To edit a spawn pattern:
Choose Simulation Spawn Pattern Manager. The Spawn Pattern Manager opens (Figure 20-2).
Click Edit Pattern. The Edit Spawn Pattern dialog box opens (Figure 20-9).
Change any value as desired. The meaning of each option is described in “Creating a Spawn Pattern,” on page 20-10.
Click Update.
Generating Traffic (Pattern of Life) — Deleting a Spawn Pattern
If you delete a spawn pattern, all spawn points of that type get deleted. Sink points do not get deleted. The spawn and sink points of this type are removed from the Create menu and Tactical Graphics Palette. If the scenario is running, any simulation objects that were spawned from these points continue executing their plans.
To delete a spawn pattern:
Choose Simulation Spawn Pattern Manager. The Spawn Pattern Manager opens (Figure 20-2).
Select the spawn pattern that you want to delete.
Click Delete Pattern. You are prompted to confirm the deletion.
Click Yes.
21. Crowds and Multiple Simulation Objects
This chapter explains how to create many simulation objects at one time and how to create and task pedestrian crowds.
Creating Multiple Simulation Objects and Crowds 21-2
Creating Crowds Using a Pedestrian Area 21-2
Adding Entities to a Pedestrian Area 21-3
Creating Multiple Simulation Objects 21-5
Adding an Area for Multiple Simulation Object Creation 21-8
Specifying the Simulation Objects to Create 21-8
Pedestrian-Oriented Tactical Graphics 21-9
Using Civilian Visit Points 21-10
Crowds and Multiple Simulation Objects — Creating Multiple Simulation Objects and Crowds
VR-Forces can quickly create multiple simulation objects within an area. This allows you to create crowds, traffic, or other multi-object groups without having to place each simulation object by hand. You can use any of the following methods to create multiple objects:
Pedestrian area. A pedestrian area gets populated by a random number of male and female civilians. They execute a wander task.
Multiple simulation objects. You can specify the number of simulation objects to create, the type of objects to create, and you can assign tasks and set data requests to them.
Crowd unit. Create a crowd unit from the Simulation Objects Palette or aggregate individual humans into a crowd unit. Assign crowd-specific tasks to the crowd.
When you create a pedestrian area, VR-Forces populates it with a random number of male and female civilian entities. They are created as a ground unit. They are all assigned a wander task. You cannot specify the number of entities to create or the mix of entities to create.
!
!
If you delete a pedestrian area, all of the entities that were created for it are also deleted.
You can create pedestrian areas only in navigation areas.
To create a crowd using a pedestrian area:
Open the Hazards/Obstacles Palette.
Select Pedestrian Area.
Draw an area on the terrain as you would any other areal tactical graphic. When the area is completed, VR-Forces creates entities to populate the area.
Crowds and Multiple Simulation Objects — Creating Crowd Units
After you create a pedestrian area, you can automatically add additional entities to the area.
To automatically add entities to a pedestrian area:
Select the area.
Choose Task Create Pedestrians. The Create Pedestrians dialog box opens.
Specify the number of pedestrians to create.
Select a placement option.
Select or clear the Restrict To Area check box.
Click OK. The pedestrians get added to the area.
VR-Forces has three preconfigured crowd units: small, medium, and large. They create a unit of civilian males and females. You can also create crowd units by aggregating individual human entities. However, some of the animations used in crowd tasks are specific to the civilian characters used in the supplied units.
When you place a crowd, if the terrain has pedestrian paths or other pedestrian-specific locations, the members of the crowd are placed in these locations.
Crowd members get created within a configurable radius of the location you specify, with a configurable density. By default, crowds are created using the parameters in Table 21-1. You can change the values in the Simulation Object Editor.
Unit | Radius (m) | Density | Approximate Size* |
Civilian Crowd (Small) | 15 | 2 | 50 |
Civilian Crowd (Medium) | 30 | 2 | 100 |
Civilian Crowd (Large) | 50 | 2 | 175 |
*If there are not enough valid locations to place entities, the size of the unit may be smaller than the theoretical maximum.
Crowd units are supported only in entity-level scenarios.
!
!
You can create preconfigured crowds only in navigation areas and crowd tasks can be executed only in navigation areas. Although you can aggregate individual entities into a crowd outside of a navigation area, they will not be able to execute any crowd tasks.
Crowds and Multiple Simulation Objects — Creating Crowd Units
To create a crowd:
Click the Simulation Objects Palette.
Select the Unit category.
Select the Civilian Crowd (Small), Civilian Crowd (Medium), or Civilian Crowd (Large) unit.
Click on the terrain to place the unit.
Crowds can execute some of the tasks available to other ground units. They have the following movement tasks:
Crowd around a location.
Crowd around an object.
Gather in front of an object.
Flee.
Wander.
Protest.
Disperse Crowd.
When a crowd gathers around a location or object, VR-Forces calculates a target destination for each member of the crowd and each member of the crowd tries to move to that destination. If you send two or more crowds to the same location or object, these target destinations may overlap. Individual entities may give up on their movement tasks or may end up very close to members of the other crowd.
For details about each task, please see its section in Chapter 30, Embarkation, Wait, Radio, and Other Tasks.
You can add multiple simulation objects to a scenario in one operation and assign them a common task. The simulation objects are added to the scenario as members of a selec- tion group. (For information about selection groups, please see “Using Selection Groups,” on page 17-7.) Creation of multiple simulation objects has the following constraints:
The simulation objects are added within a specified area. If an appropriate area does not already exist, you can create one as part of the simulation object creation process.
If the area you choose for placing simulation objects is too small to contain the number of simulation objects that you specify, some simulation objects might not be created.
When you create multiple simulation objects, VR-Forces automatically puts them in a selection group named group_number, where number starts at 0 and is incremented for each group created.
In Figure 21-1, Area 1 overlaps the navigation data. If, for example, you try to place 25 entities in this area, they are placed only in the portion of Area 1 that overlaps naviga- tion data, and only the number of simulation objects that fit in this subset of Area 1 are created.
If VR-Forces cannot create the number of simulation objects specified (due to one of the reasons mentioned in this section), there is no notifica- tion. It is your responsibility to check to see how many simulation objects were created.
Creating multiple simulation objects as described in this section is not the same thing as pattern of life traffic generation or creating simulation object groups. It is just a way to create a lot of simulation objects at one time and give them a task. And unlike creating crowds, which only contain civilians, you can create any type of simulation object.
Terrain
Area 1
navigation data
Terrain
Area 1
navigation data
Figure 21-1. Placement of multiple simulation objects
If the terrain does not have navigation data, the accessibility check is disregarded and the simulation objects get created.
If the terrain has navigation data and if the candidate location cannot use naviga- tion data to reach the waypoint, VR-Forces does not create the simulation object at that location. It tries to find another location at which to place the simulation object. If after multiple attempts to place a simulation object the accessibility check still fails, VR-Forces proceeds as follows:
If this is the first simulation object that VR-Forces has tried to create, the accessi- bility check is disregarded and VR-Forces creates the simulation objects (within the constraints previously mentioned).
If the accessibility check fails for any simulation object after the first simulation object was created, VR-Forces assumes there is no more space in which to create simulation objects and stops trying to create them.
To add multiple simulation objects to a scenario:
Choose Create Multiple Simulation Objects. The Create Multiple Simulation Objects dialog box opens (Figure 21-2).
Optionally, change the name of the selection group.
In the Select Area group box, type the name of the area in which you want to create the simulation objects, or select the area from the list or on the map. If the area in which you want to create the simulation objects does not exist, add a new area as described in “Adding an Area for Multiple Simulation Object Creation,” on
In the Define Entities To Create group box, add the simulation objects that you want to create. For details about this part of the procedure, please see “Specifying the Simulation Objects to Create,” on page 21-8.
Optionally, edit or remove any of the entity sets listed in the Define Entities To Create list.
Optionally, select the Accessibility Check check box. If you select this check box, select a waypoint. You can create a waypoint from this dialog box if necessary.
Click Create. The entities are created in the specified area.
To add an area from the Create Multiple Entities dialog box:
In the Select Area group box, click Add. A Create Area tab is added to the window.
Create an area following the standard VR-Forces procedure for creating areas. For details, please see “Placing Objects,” on page 16-11.
When you add multiple simulation objects to a scenario, you can specify any of the supported object types and assign a common task or set data request to a specific set of simulation objects.
To specify the simulation objects to add in the Create Multiple Entities dialog box:
In the Define Entities to Create group box, click Add. The Add Group of Entities dialog box opens (Figure 21-3).
In the Number of Entities box, specify the number of simulation objects you want to add for this set.
Crowds and Multiple Simulation Objects — Pedestrian-Oriented Tactical Graphics
Click the Select button that is next to the Type of Entity text box. The Entity Type dialog box opens. The list of object types available is the same list of simulation objects provided on the Simulation Objects Palette.
Select the object type you want to add. The dialog box closes and the object type is listed in the Type of Entity box.
Optionally, specify a starting set data request by clicking the Sets button and selecting a set data request. The list is not context sensitive. You must ensure that the selected set data request is appropriate to the object type that you are adding.
Optionally, specify a starting task by clicking the Tasks button and selecting a task. The list is not context sensitive. You must ensure that the selected task is appro- priate to the object type that you are adding.
Optionally, select an option in the Placement group box. VR-Forces will try to place the simulation objects in the desired location.
Optionally, set a speed and variance range.
Click OK. The object set is added to the list in the Define Entities To Create group box (Figure 21-2).
Optionally, add additional object sets.
VR-Forces has the following tactical graphics that are particular to pedestrians. These objects only work in navigation areas.
Pedestrian path. When humans plan paths in navigation areas that have navigation data, if a pedestrian path is present that can take them to their destination, they will use it. You can think of a pedestrian path as a route that a human will automatically choose to follow instead of being told to follow it. Pedestrian paths are supported only for entity-level scenarios. Pedestrian paths are created from the Hazards/Obstacles Palette.
Crosswalks. Crosswalks are similar to pedestrian paths. Pedestrians prefer them when path planning. The unique aspect of crosswalks is that if an entity is config- ured with a human crosswalk controller, it checks to see if it is safe to cross the street before proceeding. Crosswalks are created from the Hazards/Obstacles Palette. (Crosswalks are an experimental feature. Please contact support@mak.com if they do not work as you expect.)
Pedestrian areas. Pedestrian areas automatically generate pedestrians when you create them. Pedestrian areas are created from the Hazards/Obstacles Palette.For details, please see “Creating Crowds Using a Pedestrian Area,” on page 21-2.
Crowds and Multiple Simulation Objects — Pedestrian-Oriented Tactical Graphics
Civilian visit points are waypoints that attract the attention of civilian entities that are walking nearby. The civilians can be members of a crowd or individual entities. When a civilian comes within a configurable distance of a civilian visit point, it stops and faces the point a configurable percentage of the time. If it stops, it waits a few seconds and then continues its task.
This behavior is controlled by the Visit Interest Points reactive task. You can edit the parameters that control an entity’s behavior in the Manage Reactive Tasks dialog box. For more information about reactive tasks, please see “Reactive Tasks,” on page 26-12.
VR-Forces has two, quite different, ways to model simulation objects – entity-level modeling and aggregate-level modeling. These modeling approaches affect how units are modeled.
The chapters in this section provide conceptual background about modeling units, how to create them, and how to display them.
VR-Forces Users Guide
Section IV - Modeling Units
IV-1
Modeling Units
Section IV - Modeling Units
IV-2 VT MAK
22. Entity-Level Unit Modeling
This chapter describes how units are modeled in entity-level scenarios.
Units in Entity-Level Scenarios 22-2
How Units Carry Out Tasks 22-5
In entity-level scenarios units are simulated in either of two states:
Disaggregated: Subordinates are simulated and published as individual entities (Figure 22-1). The members of a unit can move individually through the scene, have their own plans, interact with other simulation objects, and do all the things you would expect of an individual entity. When a unit engages in combat, the indi- vidual members of the unit fight the opposing forces using their weapon systems and survive or die as individuals.
Units in this state can be tasked and given plans, but usually pass responsibility for execution to their subordinates. For example, if you give a disaggregated unit a movement task, each member of the unit plots a path and follows it.
Aggregated: Subordinates are not simulated separately. Tasks and plans are executed by the unit. For example, if you give an aggregated unit a movement task, the object representing the unit moves.
Plt 1 Plt 2
Disaggregated Aggregated
Figure 22-1. Disaggregated and aggregated units
The disaggregated and aggregated states are not the same as expanded and collapsed units (which are explained in “Expanding and Collapsing Units,” on page 25-2.). Expanded and collapsed units are simply different visual representations of the unit. Aggregated and disaggregated states are different simulation states.
An aggregated unit in an entity-level scenario is similar to a unit in an aggregate-level scenario in that there is no representation of subordinates. However, an aggregated unit can disaggregate and model subordinates, whereas a unit in an aggregate-level scenario cannot do so. Furthermore, their underlying modeling is completely different.
Although it is theoretically possible for an entity-level scenario to have units that cannot be disaggregated into individual vehicles and persons, EntityLevel.sms does not have any units of this type.
A unit can support either of these states. At any given time, one subset of components and systems is enabled, and the other is disabled. At runtime, you can switch dynami- cally between these states.
You can configure VR-Forces so that unit state is determined automatically according to a set of rules, or to have unit state controlled manually.
The choice of whether or not to simulate units in the aggregated or disaggregated state depends on your goals for the simulation. For example, if you need to support large numbers of simulation objects, and do not want or need to simulate individual entity behavior, then you may want to simulate some or all of your units in the aggregated state. Conversely, if you need to simulate the detailed behavior of subordinates, then you will want to simulate units in the disaggregated state.
!
!
A unit in the aggregated state only simulates movement behavior. It does not model combat behavior. If you want a unit to model attrition, simulate it in the disaggregated state. A unit in the aggregated state keeps track of its current resource and attrition state. If a unit later transitions to a disaggregated state, this state information is preserved.
For more details about the differences between aggregated and disaggregated units, please see Chapter 24, Creating and Controlling Units.
The organization within a disaggregated unit is based on the echelon ID of each member. For example, in Table 22-1, four unique entities (identified by name) are assigned designators in 2 Plt.
Table 22-1: Example of names and echelon IDs
Name Echelon ID
Name Echelon ID
Tank 1 1 M1A2, 2 Plt, 1 Force
Tank 2 2 M1A2, 2 Plt, 1 Force
Tank 3 3 M1A2, 2 Plt, 1 Force
Tank 4 4 M1A2, 2 Plt, 1 Force
Assignment of echelon IDs is handled automatically by VR-Forces when you create a unit.
Reorganization is the reassignment of echelon IDs to the members of a unit when a member gets destroyed. If reorganization is enabled, when a member of a unit gets destroyed, the destroyed member is assigned the highest numerical ID in the unit, and the surviving members' echelon IDs are moved down numerically by one. For example, assume a platoon as shown in the leftmost table in Figure 22-2. If 2 M1A2 (currently the entity named Tank 2) gets destroyed, reorganization would result in the new echelon ID assignments illustrated in the rightmost table. The former 3 M1A2 is now 2 M1A2, former 4 M1A2 is now 3 M1A2, and the former 2 M1A2, is now 4 M1A2. Their echelon IDs have changed. Their names and object IDs have not.
Echelon ID Name
M1A2 Tank 1
M1A2 Tank 2
M1A2 Tank 3
M1A2 Tank 4
Echelon ID Name
M1A2 Tank 1
M1A2 Tank 3
M1A2 Tank 4
M1A2 Tank 2
Figure 22-2. Reorganization of Platoon 2
You can configure VR-Forces to reorganize units automatically, or you can reorganize manually. Manual reorganization does not require you to reassign each designator; you simply order the unit to reorganize with the Reorganize command.
i Reorganization only applies to disaggregated units.
When a disaggregated unit receives a movement command, VR-Forces calculates the path the unit leader must follow for movement. Then it calculates parallel paths (taking into account the formation) for each member of the unit. The unit members are then responsible for following these paths until the unit completes the movement task.
The process of closing formation is internal to a unit. Formation position is not reported as part of simulation object information. The only way to determine a simula- tion object’s formation position is to observe the formation as the unit moves.
Closing formation is an inherent feature of units in the VR-Forces application. You do not need to do anything to put it into effect and you cannot turn it off.
Closing the formation of the entities in a unit is not the same thing as reorganization. Reorganization changes the echelon designators of its members. Closing formation does not change the echelon designators of unit members, or the tasks a simulation object is assigned. It only affects the relative positioning of members within a formation.
If a unit is in the aggregated state, it does not send task messages to subordinates. However, if while carrying out its task the unit disaggregates, it sends appropriate task messages to its subordinates to continue with the task execution. For example, suppose a unit is moving to a point and its path to the point passes through a disaggregation area. When it enters the disaggregation area, it would disaggregate, calculate routes for its subordinates, and send them Move Along Route tasks. When the unit exits the disaggregation area, it aggregates again and the tasks for its subordinates are abandoned.
Disaggregation areas are special control objects. If automatic aggregation and disaggregation is enabled, when a unit enters a disaggregation area, it automatically disaggregates. When it leaves the area it aggregates. For more information, please see “Using Disaggregation Areas,” on page 24-12.
The precise way in which a unit sends out messages to its subordinates is part of the modeling of the unit that is built into the VR-Forces application.
23. How Aggregate-Level Modeling Works
This chapter describes the aggregate warfare model and how simulation objects created using AggregateLevel.sms work.
The Aggregate Warfare Model 23-2
Combat Engineering Objects 23-9
Creating Combat Engineering Objects 23-11
How Engineering Units Create Engineering Objects 23-12
Sensing Electronic Emissions 23-18
VR-Forces supports a warfare model for aggregate-level scenarios. The aggregate warfare model requires use of AggregateLevel.sms or a similar SMS and only works with HLA Evolved and the MAK FOM extensions.
The aggregate warfare model is data-driven. Simulation objects have combat power and combat vulnerability. Their overall state is expressed as their health. These are abstract values that represent relative strengths of different units.
When opposing force simulation objects come into contact, they inflict damage on each other until one of the simulation objects is destroyed or breaks off combat. A unit is considered killed when its health is 0.
Some of the features that distinguish aggregate-level scenarios from entity-level scenarios include:
Footprint. The area occupied by the unit.
Posture. The unit’s mode of interaction with the environment.
Logistics. Management of personnel and matériel.
Combat engineering objects. Tactical graphics that affect simulation object move- ment and health.
Electronic warfare. The ability to jam communications.
Reports. Some data tracked in a simulation, such as personnel levels and pacing and tracking, is not used by the back-end. It is sent over the network to be used by command and control systems and human participants.
AggregateLevel.sms includes some individual entities, such as surface vessels and aircraft. However, these entities also use the aggregate warfare model. They do not behave like they would if you were using the same entity types in entity-level modeling.
Combat power is the ability of a simulation object to cause casualties and damage, and is a function of how many weapons it has, the size (destructive power) of their muni- tions, the rate of fire of the weapons, the accuracy of the weapons, and the effectiveness of the subordinate simulation objects in conducting an attack (tactics, coordination, target selection, and so on).
A simulation object’s ability to engage in combat is expressed as a strength value in one or more of the following five domains:
Anti-air
Anti-tank
High explosive
Anti-personnel
Anti-ship.
The strength value describes the attrition rate per second imposed on the target by the attacking unit.
A combat domain has a range. When an opposing force simulation object is within the range of a combat domain for which a simulation object has strength, it attacks the simulation object.
Health is a function of the amount of equipment, personnel, or both in the simulation object, and the difficulty in destroying them. For example, a unit with 10 tanks would have twice the health of a unit with 5 of the same kind of tank. However, note that the initial health for a unit is set by the SMS designer in the Simulation Object Editor. It is independent of other parameters or resource variables. It is not computed based on the equipment in the unit. Also, health values in different domains are not usually compa- rable to each other. They are only meaningful relative to units in the same domain.
Simulation objects also have a vulnerability in each of these domains. Base vulnerability describes how susceptible a simulation object is to a given category of weapon. In particular, it describes how easy it is to hit and kill the equipment in the simulation object with the given category of weapon. For example, infantry is very susceptible to high explosive munitions, light armor fairly susceptible, and heavy armor not very susceptible.
Vulnerability is expressed as a modifier of the combat power (attrition rate) of the attacker. It is multiplied by the attrition rate to calculate the actual damage. For example, a Mech Inf CO US has an Anti-personnel strength of 78. A Mech Inf CO RU has an Anti-personnel vulnerability of .1. If the US company attacks the Russian company, the actual damage for personnel will be 78 * 0.1 = 7.8 per second.
Both combat power and vulnerability are modified by a variety of factors, including posture, MOPP level, sector, and morale. The combination of all modifiers results in the final attrition rate.
The attrition across all domains is applied to the simulation object’s health. If health declines to 0, the simulation object is killed.
The physical footprint has four sectors: front, rear, left flank, and right flank. The inter- actions of the unit with other simulation objects in the scenario varies based on which sector another entity is encountered on. For example, a unit is typically much more vulnerable to attack on the rear and flank sectors.
Both the physical footprint size and the size of the sectors for a unit are configured with a base value, but can then change during the scenario depending on actions of the unit.
i The footprint is always circular. The footprint parameter describes the radius.
Posture is an abstraction of the positioning of the equipment and personnel of a unit within its physical footprint, and its state of readiness for various activities.
Rout. Health is less than 50% and unit is under attack. It cannot change to another posture until its health exceeds 50%.
A unit’s posture affects:
Footprint. The amount of space that the unit occupies.
Sensor signature. The ability of other units to detect a unit is affected.
Movement speed.
Sector sizes.
Combat power. Many weapon systems can only be used in certain postures. In particular, most cannot be used in Travel posture (which is the posture a simulation object is in when it is created).
Vulnerability.
When a unit transitions between postures, it does so over time. Transitions may take up to several hours. The transition delay models the planning and preparation necessary to perform the task expected in the new posture. For example, deliberate defense is a well prepared defense that assumes planning fires, digging fighting positions, and so on. It significantly reduces the vulnerability of the defender. However, it may require 3 hours to transition to this posture. Hasty attack is the only posture that does not require a long transition time, as it is the posture for quick actions on contact, meeting engage- ments, pursuits, and so on. Transition times between each posture are configured in the Simulation Object Editor.
Because transitioning between postures can take hours of simulation time, when you set up a scenario you must decide if you want units to start in a given posture or transition to it as part of the simulation.
Defense postures assume stationary defense.
Aircraft and ships generally do not distinguish postures, except that they are not battle- ready in Travel posture.
The slope of the terrain and the broad categories of the terrain underneath the unit, alter the maximum possible travel speed.
Roads allow units to move more quickly, while restricted areas like forests or cities slow them down.
Rivers and water bodies may stop a unit completely, although bridges allow them to cross.
Overlapping footprints cause units to slow down.
The movement speed modifiers for slope, terrain, footprint overlap, MOPP, posture, and so on only affect maximum speed. If ordered speed is less than the net modified maximum speed, you will not see a change in speed due to these factors.
For movement speed calculations, the center point of the unit is used to determine what type of terrain the unit is on.
If the footprints of two units overlap, their movement is slowed based on their Max Speed Modifier When Overlapping Another Unit parameter. This parameter is set on the Movement tab for a unit in the Simulation Object Editor. The lower the value, the greater the movement penalty. When unit footprints overlap, the lowest modifier among all overlapping units is applied to all of them.
Aggregate-level scenarios do not support collision avoidance among simulation objects.
The effect of terrain features on movement is configured in a unit’s movement system.
For details, please see “Configuring Aggregate-Level Movement Restrictions,” on page 62-9.
VR-Forces supports a variety of combat engineering objects that affect entity move- ment. They may cause a unit to go more slowly or they may damage the unit. For infor- mation about combat engineering objects, please see “Combat Engineering Objects,” on page 23-9.
Individual missile attacks typically make use of a hit factor from the attacker and a defense factor from the defender to determine a hit probability. The missile must hit before its combat power is applied in an attack.
Contamination areas have parameters that are similar to other areal tactical graphics, plus the following parameters:
Agent type. The type of contamination. It determines the configuration used for damage calculations.
Terrain type. Informational only; not used by VR-Forces.
Topography type. Informational only; not used by VR-Forces.
Vegetation type. Informational only; not used by VR-Forces.
The terrain, topography, and vegetation types are published by VR-Forces, but do not affect unit modeling or interaction. They may be useful to other applications that interact with VR-Forces.
By default, NBC hazard areas are placed on the Contamination Areas overlay.
When a unit is attacked by NBC weapons or enters an NBC area, it suffers attrition. It stops its current task and increases its mission oriented protective posture (MOPP) level until it stops suffering attrition. Then it resumes its task. However, any contamination that took place persists.
Increasing MOPP level affects a unit’s speed, combat effectiveness, sensor sensitivity, posture transition time, and vulnerability.
Some types of contamination are benign enough that they cause little, if any, damage to simulation objects. Other types, such as gamma rays, cause attrition even at the highest MOPP level.
Simulation objects in aggregate-level scenarios use the same sensor signature mecha- nism as simulation objects in entity-level scenarios. Sensor systems allow them to detect other simulation objects in various domains. Sensor signatures indicate how detectable they are by other simulation objects in the applicable domains. The main difference between simulation objects in the two types of modeling is in the detection checks.
Footprint Footprint
Figure 23-1. Aggregate-level sensing
VR-Forces supports a variety of combat engineering objects that affect unit movement. They may cause a unit to go more slowly or they may damage the unit. Combat engi- neering objects (CEOs), such as fortifications, can also protect a unit, in that they affect the effectiveness of opposing forces.
CEOs are displayed as tactical graphics. You can create combat engineering objects from the Hazards/Obstacles Palette. Also, units can create combat engineering objects in response to combat engineering object tasks.
Units can counter the presence of combat engineering objects by breaching them, bridging them, defusing them, or destroying them.
Combat engineering objects can have the following effects on units:
Mobility. CEOs can decrease entity mobility. Mobility modifiers are configured by mobility type. For instance, an object might affect the mobility of soldiers on foot more than tanks. When a simulation object comes in contact with an engineering object, it checks the object type’s mobility modifier against the entity’s mobility type. The entity slows down based on the modifier value.
The modifier is scaled based on the completion percentage of the object. Modifiers only affect the maximum speed, so speed is affected only if the modified maximum speed is less than the current speed of the unit.
If a unit encounters an obstacle that obstructs its movement or may cause damage, it stops moving and sends a message to the console indicating that it is obstructed (Figure 23-2). The user must then tell it what to do. The console message may use the question and answer capability. (For information about console questions, please see “Answering Questions from Scripted Tasks,” on page 18-34.)
i The unit may not be able to move until you respond to the question.
If an obstacle is concealed, the unit does not stop. For information about
concealed obstacles, please see “Concealed Obstacles,” on page 23-11.
Mobility enabling. Certain types of engineering objects are treated as terrain features by a moving unit. For instance, a simulation object may determine that an engineering object represents a road or bridge, giving it additional path planning options. This capability is either on or off.
The modifier is scaled based on the completion percentage of the object.
Figure 23-2. Question in entity console
The modifier is scaled based on the completion percentage of the object.
Attrition over time. When a simulation object contacts an engineering object that causes damage (for example a minefield), that object continues taking damage over time as long as it remains in contact. The damage is configured as one of the existing damage/weapon categories, for example, high-explosive. Simulation objects with more or less vulnerability to that damage type take more or less damage accordingly.
The attrition is scaled based on the completion percentage of the object.
Immediate attrition. Some engineering objects cause one-time, immediate damage to any unit that comes in contact with them. For instance, a simulation object might trigger an IED. Usually the engineering object is destroyed in the process.
The modifier is scaled based on the completion percentage of the object.
The various modifiers are configured for each CEO in the Simulation Object Editor.
By default, minefields, booby traps and unexploded ordnance objects are concealed. (This attribute is configurable in the Simulation Object Editor, so you can set it for other objects if you want to.) The engineering object sensor does not automatically detect concealed objects within its sensing radius. The sensor has a random (configu- rable) chance of detecting the object each sensor cycle that the object is within range.
If a sensor detects a concealed minefield, the Mark Minefield reactive task marks it as detected. Thereafter, the minefield is always 100% detectable. (The Mark Minefield reactive task is enabled by default.)
Unit movement systems check the concealed flag for obstacles. For non-friendly obsta- cles that are concealed, the “stop and ask” behavior is suppressed unless the object has been specifically detected by the sensor. Therefore, if the sensor has not detected the object, the unit enters it without first stopping and alerting you to the presence of the object.
Concealed objects are always discovered if they are causing damage to a simulation object.
You can create combat engineering objects directly from the Hazards/Obstacles Palette or you can task simulation objects with the appropriate systems, such as combat engi- neering units, to create them.
Combat engineering objects are implemented as points, lines, and areas, so you can create them the same way that you would create tactical graphics. Most areal CEOs are fixed size, which is configurable in the Simulation Object Editor. You just have to specify the lower left corner of the area.
When you create a CEO from the Hazards/Obstacles Palette, you can give it a name, specify a layer and set all the parameters you would expect for that type of object. When you task a unit to create a CEO, it is given a default name and you can only specify its location.
When a unit with engineering capabilities creates a CEO, it expends construction material at a rate specified in the object’s model (configured in the Simulation Object Editor). Depending on the type of objects, the process can take hours of simulation time.
You can follow the progress of object construction in two ways. You can view the engineering unit’s use of construction material on the Supplies page of its Information dialog box. You can view the percent of the object’s completion on the Engineering Object Information page of the Information dialog box for the object (Figure 23-3).
Concertina supply Barbed wire under construction Percent complete
Figure 23-3. Road under construction
Units create combat engineering objects as follows:
The unit moves within range of the location to create the object.
The unit creates a new object that is 0% complete. The object is displayed on the terrain.
The unit begins constructing the object. As it does so, its supply of construction material decreases.
When the object is complete or the unit runs out of construction material, it ends the task.
If a creating unit is interrupted and must halt construction, it notifies that object that construction has stopped. The object stays at its current level of completion, which may or may not be useful, depending on the object type. A constructing unit might also reduce its rate of construction if it takes damage.
If the constructing unit is able to resume construction or another unit is tasked to improve the object, it moves within range of the object and construction starts again.
Multiple units with construction capability can work together. To task a second unit to assist the first, task it to improve the object under construction.
You can also set the completion percentage of a combat engineering object with the Percent Complete set data request.
Simulation objects have resources, such as fuel, ammunition, and food. Over time, and particularly during combat, these resources are consumed. Logistics is the process by which a unit resupplies itself.
Units can resupply the following resources:
Health
Food
Water
Motor gas
Aviation fuel
Diesel fuel
Oil
Lubricant
Anti-Tank
High-Explosive
Anti-Personnel
Anti-Air
Anti-Ship
Large-Munition
Other.
Anti-Tank, High-Explosive, Anti-Personnel, Anti-Air, and Anti-Ship refer to ammuni- tion in that category. There is no distinction made between different ammunition names within a category. Large-munition covers all other categories of ammunition, such as indirect fire munitions, bombs, and missiles. Other supplies covers any other type of supply, including engineering materials.
How Aggregate-Level Modeling Works — Logistics
The Supplies page on the Information dialog box indicates when a simulation object is receiving or providing supplies. You can display supply lines that show when a supply unit is supplying another unit (Figure 23-4). In Figure 23-5, green arrows show the supplies that the entity is receiving.
Figure 23-4. Supply information and supply lines
Figure 23-5. Supplies being received
Units can receive supplies in the following ways:
Take supplies from a supply unit. Units take supplies from a friendly supply unit that is within range and has notified them that it can provide supplies. The resupply range is specified in the Simulation Object Editor as part of a supply system.
Auto Resupply Continuously. Supplies increase continuously at a configurable rate.
Auto Resupply Periodically. Simulation objects refill all supplies at specified inter- vals. The interval is configurable.
The ability to resupply can be restricted if a simulation object is moving, attacking, or defending. This is configured in the Simulation Object Editor on the Supplies tab. You can change how a simulation object receives supplies using the Set Resupply Mode task. If they are configured for airborne refueling (Can Receive Fuel While Airborne param- eter), airplanes can receive fuel while they are flying, but must be on the ground to receive any other type of supply.
Simulation objects can provide supplies to other simulation objects if they have a resupply system (resupplier.sysdef). A supply unit can be configured to provide any of the supplies that are supported. A supply unit can provide supplies to any number of other simulation objects. It is assumed to have its own supply source, so it never runs out. You can change a supply unit’s status with the Change Supplying Command task.
A supply unit runs a background process that tests for friendly simulation objects in its area and notifies them that it is available to provide supplies. It checks for conditions that might prevent a simulation object from receiving supplies. It stops providing supplies to simulation objects that move out of range.
The aggregate warfare model supports three types of electronic warfare – communica- tions jamming, radar jamming, and sensing electronic emissions.
Each unit has an EW-Comms-Dependence and an EW-Defense-Strength property. The dependence property indicates how much it can be affected if its communications are jammed. The defense factor indicates how well its technology and practices protect it from communications jamming. Units also have, in their state properties, a list of jamming attacks being made against them (type and strength) and a net EW-Comms- Degradation-Percentage.
When a simulation object attacks another entity with jamming, it sends EW attack information to the target.
Simulation objects jam all enemy simulation objects in range; there is no target selection. Friendly simulation objects are not affected.
When a simulation object suffers communications jamming attacks, the strengths of all attacks are added together and compared to the defensive strength. The ratio deter- mines a modifier between 0 and 1, which is multiplied by the EW-Comms-Depen- dence. The result is a degradation percentage. This degradation percentage is applied to reduce combat power, and increase vulnerability and posture change time (by a maximum factor of 2.0).
Units can have a system called an aggregate-comms-jammer. This system has parame- ters for strength, maximum range, and a set of allowed postures. Strength falls off with 1/r2 (r is range in kilometers). This system can trigger EW attacks using the Make EW
Attack background scripted task. It has a jammer controller that can publish an emitter.
You can enable or disable the emitter using the Emitter set data request. Turning it on activates jamming, and turning it off deactivates jamming. If the emitter is turned on while the simulation object is not in an allowed posture for jamming, a warning is printed to the console. In this case the emitter is on, but it is not used for jamming attacks.
When jamming is enabled the Make EW Attack script determines which jamming systems on the simulation object are on, and then uses them to attack all targets within range. It updates (new) EW-Attacks and Jamming-Strength-On state properties on the simulation object. The Jamming-Strength-On property summarizes the strength from all jammers the simulation object has turned on, and is used for emissions sensing. The Update_EW_Degradation background script computes the effects of EW attacks on a simulation object.
How Aggregate-Level Modeling Works — Electronic Warfare
The MI PLT (military intelligence platoon) unit is configured to have an aggregate- comms-jammer.
Each unit has a state property Radar-Jamming-Strength-Receiving, which is updated by the Update_EW_Degradation background script. This is the total radar jamming strength being received.
Radar jamming can have the following effects:
Reduce the sensitivity of radar sensors so they cannot detect targets.
Reduce the hit factor of radar-homing missiles so they have a smaller hit proba- bility.
The active-radar-sensor system has a parameter called jamming-defense-factor. This factor reflects the technology of the radar (not power) and is used with the jamming strength received to compute a sensitivity modifier for the sensor. The modifier varies from 0 to 1.
The weapon systems that use a controller that uses an aggregateReleaseBombControl- lerDescriptor have parameters can-be-radar-jammed and jamming-defense-factor. This includes the following weapon systems:
aggregate-antiair-missile
aggregate-antiship-missile
aggregate-land-attack-missile
aggregate-release-bomb
aggregate-unguided-bomb.
If can-be-radar-jammed is true, then jamming-defense-factor is used with jamming strength received to calculate a modifier for the hit factor of the weapon.
Weapon systems are configured with either a constant or variable for can-be-radar- jammed, to provide examples of different guidance systems:
Anti-air missiles use a variable, to allow modeling of IR or radar-homing missiles.
Anti-ship missiles set can-be-radar-jammed true, thus assuming radar guidance.
Land attack missiles use a variable.
Release-bomb omits the parameter (default is false), to simulate optical guidance.
Unguided bomb omits the parameter (default is false).
The aggregate-radar-jammer system can publish an emitter and can be turned on and off using Emitter set data request. It enables the EW_Attack script.
The radar jammer strength falls off with 1/r2 (r is range in kilometers). The EA-18G entity is configured with a radar jamming system.
The emission sensor domain allows simulation objects to sense RF electromagnetic emissions from simulation objects. Each simulation object has an emissions signature, which is a parameter for each object type. This can be detected by the SIGINT sensor. This is the “normal background signature”.
There is a sensor signature modifier for emissions. VR-Forces determines if specific emitters are turned on, thus adding to the normal background signature for the simula- tion object .
The emissions signature modifier has a parameter, jam-strength-factor, that converts jamming strength to a signature value. It is set in the platform files.
There is a sensor system emissions-sensor for emissions. It is called a SIGINT (signals intelligence) sensor. The MI PLT unit is configured with a SIGINT Sensor.
24. Creating and Controlling Units
This chapter explains how to create and manage units.
Creating a Unit by Combining Existing Simulation Objects 24-2
Creating a Preconfigured Unit 24-5
Configuring the Unit Creation State 24-6
Adding Simulation Objects to a Unit 24-7
Removing a Simulation Object from a Unit 24-8
Units and Unit State in Entity-Level Scenarios 24-8
How a Unit’s State is Shown 24-9
How Changing Aggregation State Affects a Unit 24-10
Triggering Unit State Transitions 24-11
Aggregating and Disaggregating Units Manually 24-12
Configuring Automatic Aggregation and Disaggregation 24-12
Using Disaggregation Areas 24-12
When you create a unit, it is created as a subordinate to the force level. You cannot create units that are subordinates of an existing unit. Once you create a unit, you can subordinate it to another unit. (For details, please see “Adding Simulation Objects to a Unit,” on page 24-7).
Except where noted, the procedures for creating and editing units apply to entity-level scenarios and aggregate-level scenarios.
When you create a unit, the members of the unit get new echelon IDs to reflect the new entity hierarchy.
If the simulation objects that you are aggregating have plans and your unit setting is to aggregate new units, the plans are deleted. However since individual plans get deleted whenever a unit enters the aggregated state, in entity-level scenarios you cannot count on simulation objects keeping their plans even if you change this setting.
To create a unit by combining existing simulation objects:
Select the simulation objects that you want to become part of a unit.
Choose Objects Aggregate As. The Aggregate As dialog box opens (Figure 24-1).
Select a unit type from the list.
The Convoy unit can only be assigned convoy tasks. Its only purpose is to allow you to quickly aggregate miscellaneous ground vehicles into a convoy. You cannot aggregate or disaggregate a convoy.
The default list of unit types is limited and is different for entity-level scenarios and aggregate-level scenarios. You can specify the unit types that are on the list in the Simulation Object Editor. For details, please see “Specifying an Aggregate As Option,” on page 66-3.
Optionally, customize the entity type enumeration for the unit, as follows:
Click More. The dialog box expands to show the entity type enumeration for the unit type selected (Figure 24-2).
Edit the enumeration by selecting values from the lists, or by typing an enumer- ation.
If an edit to the enumeration results in an entity type that does not match the unit type selected in the list, the list entry does not change. However, the unit will be created with the entity type specified by the custom enumeration.
Optionally, change the order of subordinates, as follows:
Select the subordinate whose order you want to change.
Click the up or down arrow to move it to a new position in the list of subordi- nates.
Click OK.
Creating Higher Echelon Units in Aggregate-Level Scenarios
In aggregate-level scenarios, you can combine entities and units to create higher echelon units just as you can in entity-level scenarios. However, unlike in entity-level scenarios, you cannot switch these units between an aggregated and disaggregated state. They are always disaggregated.
EntityLevel.sms and AggregateLevel.sms include preconfigured units at several hierar- chical levels. You can configure them and add additional units in the Simulation Object Editor. (For details, please see “Editing Unit Composition,” on page 66-4.)
You create preconfigured units by selecting them on the Simulation Objects Palette and follow the standard procedures for creating simulation objects. The abbreviations in the unit names in EntityLevel.sms have the following meanings:
ADA. Air defense artillery.
COLT. Combat observation lasing team.
CSS. Combat service support.
FA. Field artillery.
MI. Mechanized infantry.
By default, units in entity-level scenarios are created in a disaggregated state. You can change the default aggregation state. For details, please see “Configuring the Unit Creation State,” on page 24-6.
Creating and Controlling Units — Selecting a Unit
This procedure only applies to units in entity-level scenarios.
To configure the aggregation state used when units are created:
Choose Settings Application. The Application Settings dialog box opens.
Select the Entity Behavior Options page (Figure 24-3).
In the Initial Unit State group box, select the creation option that you want.
Click OK.
To select a unit, select its icon on the terrain, or select it in one of the views on the Objects List Panel.
Creating and Controlling Units — Adding Simulation Objects to a Unit
To add a simulation object to a unit, in the Echelon View, select the simulation object you want to add and drag it onto the unit as illustrated in Figure 24-4. Notice that the name of the simulation object stays the same, but its echelon ID changes.
You can add simulation objects to a unit in an entity-level scenario only if it is in the disaggregated state.
You can also add simulation objects to a unit with the Superior set data request. For details, please see “Superior,” on page 34-42.
Figure 24-4. Adding a simulation object to a unit
Creating and Controlling Units — Removing a Simulation Object from a Unit
To remove a simulation object from a unit, in the Echelon View, drag the simula- tion object from the unit to the force level in the window, as illustrated in Figure 24-5, or into another unit. Notice that the name of the simulation object stays the same, but its echelon ID changes.
You can remove simulation objects from a unit in an entity-level scenario only if it is in the disaggregated state.
You can also remove simulation objects from a unit with the Superior set data request. For details, please see “Superior,” on page 34-42.
Figure 24-5. Removing a simulation object from a unit
In entity-level scenarios, units can switch back and forth between the aggregated state and the disaggregated state. It is important to understand the differences between these states. The types of units are introduced in Section 22.1, “Units in Entity-Level Scenarios”. This section provides additional details about how units function in the two different aggregation states.
i The Convoy unit does not support aggregation and disaggregation.
Creating and Controlling Units — Units and Unit State in Entity-Level Scenarios
Units publish their aggregation state using the DIS/RPR FOM aggregate state enumer- ation. The current value for this parameter is displayed on the State Data page in a unit’s Information dialog box (Figure 24-6). It can be accessed in the unit’s DtVrfAggre- gateStateRepository member.
Creating and Controlling Units — Units and Unit State in Entity-Level Scenarios
Units can change their aggregation state at runtime. All state information maintained by the unit (for example, the current task it is executing, plan state, current resource levels) is maintained across the transition between aggregated and disaggregated states. This section describes how units handle transitions for the most important activities.
Units preserve their formation across unit state transitions.
>disaggregate transition are not restored. To fully recover all subordinates, restore the unit while in the aggregated state.
Creating and Controlling Units — Triggering Unit State Transitions
While a unit is disaggregated, its members can be given tasks and plans. However, when the unit aggregates, all tasks and plans are discarded. If the initial unit creation state is set to Aggregated and you create a unit from existing simulation objects, if the simula- tion objects have plans, the plans are discarded. (For information about settings the initial aggregation state, please see “Configuring the Unit Creation State,” on
You can initiate unit state transitions manually or automatically, as follows:
Manually: You can send a Unit State set data request or use Aggregate and Disag- gregate commands on the Objects menu. This immediately forces the unit to change state. As a set data request, state changes can be included in plans.
Automatically: On the Entity Behavior Options page of the Application Settings dialog box, you can configure automatic aggregation and disaggregation. In auto- matic mode, units automatically aggregate or disaggregate according to the following rules:
If the unit is within “disaggregation range” of a hostile entity or unit, the unit is in the disaggregated state. Disaggregation range is the range around a simulation object or unit in which you want to force any nearby aggregated units to disag- gregate so you can detect or engage them. This range is configurable for every type of entity and unit in the Simulation Object Editor. (You must show advanced parameters to set this parameter.)
If the unit’s formation footprint (projection of its bounding extent in a topo- graphic plane) overlaps a disaggregation area, the unit is in the disaggregated state. (A disaggregation area is a specific type of control object.)
If neither of the above conditions is in effect, the unit is in the aggregated state.
Creating and Controlling Units — Writing Plans for Units
To aggregate a disaggregated unit:
Select the unit.
Choose Objects Aggregate.
You can also change a unit’s state with the Unit State set data request (which also means that you can change state from within a plan).
To disaggregate an aggregated unit:
Select the unit.
Choose Objects Disaggregate.
To configure automatic aggregation and disaggregation:
Choose Settings Application. The Application Settings dialog box opens.
Select the Entity Behavior Options page (Figure 24-3).
In the Aggregate/Disaggregate group box, select Automatically or Manually.
Click OK.
To write a plan for a unit, follow the procedures for writing a plan for a simulation object in Chapter 36, Writing Plans.
Creating and Controlling Units — Deleting a Unit
! If you delete a unit, all its members get deleted.
Select the unit.
Choose Objects Delete.
Creating and Controlling Units — Deleting a Unit
Many aspects of managing units are the same as for individual entities. This chapter focuses on features that are unique to units.
Expanding and Collapsing Units 25-2
Expanding and Collapsing Units in the Echelon View 25-4
Expanding and Collapsing the Echelon View by Level of Aggregation.. 25-4 Displaying Ghosted Icons 25-6
Displaying Unit Icons and Bounding Volumes 25-9
Specifying the Color Scheme for Unit Bounding Volumes 25-11
Displaying Units — Selecting Units
You can select units in the same ways that you can select entities. (For details about selecting entities, please see “Selecting Simulation Objects, Tactical Graphics, and Props,” on page 17-4.) However, to select a unit, you must select the unit icon, not individual members of the unit. If a disaggregated unit is expanded, the unit icon might not be visible. To select the unit, you can collapse it, or you can select the unit in the Echelon View.
You can display disaggregated units in expanded or collapsed mode. When a unit is collapsed, it is displayed as one icon. When a unit is expanded, all the members of the unit are visible as individual entities or subordinate units and the unit icon is hidden. Multi-level units can expand and collapse at each level of aggregation. For example a company could be collapsed to the company level (one icon), the platoon level (an icon for each platoon), or fully expanded.
Aggregate-level scenarios do not support aggregation and disaggregation of units. Units are always disaggregated. Therefore, they can always be expanded and collapsed.
When you Expand or Collapse a unit, you can expand or collapse one level of aggrega- tion or all levels. When you Expand or Expand All, expansion is downward from the current unit and does not affect any sibling units. When you Collapse, contraction is upward in the hierarchy. Collapse All collapses all members of the unit to the topmost level.
Figure 25-1 illustrates these relationships. Assume a company with three platoons, each of which has four vehicles.
If you Expand the top level unit, it expands to the platoon level. (1)
If you select Plt C and choose Expand or Expand All, it expands just Plt C. (2)
If you select the top level unit and expand all, it expands to the leaf level – 12 indi- vidual vehicles. (3)
If the unit is fully expanded and you select one member of Plt C and choose Collapse, just Plt C collapses. (4)
If you select any member of an expanded unit and select Collapse All, the entire unit collapses. (5)
Fully collapsed
Plt C
Expand 
Expand Plt C 
Expand All 
(from top)
Collapse 
Plt C
Collapse All
Figure 25-1. Unit expand and collapse
A unit’s icon does not indicate whether it is aggregated or disaggregated. However you can easily infer its state from the Objects menu or the Echelon View. The unit commands on the Objects menu are context sensitive. If you select a unit and the Disaggregate command is available, then the unit is in the aggregated state. Similarly, if you view a unit in the Echelon View, if it is aggregated, you cannot expand it in the tree. If it is disaggregated, you can expand it to see its subordinates.
You can also view its state explicitly on the State Data page of the Information dialog box.
To expand a unit, right-click the unit icon or its entry in the Objects List Panel and choose Expand on the popup menu.
To expand a unit and all its subordinate units, right-click the unit icon or its entry in the Objects List Panel and choose Expand All on the popup menu.
To collapse a unit one level, right-click any member of the unit and choose Collapse
To collapse a unit to its root level, right-click any member of the unit and choose
Collapse All on the popup menu.
Displaying Units — Expanding and Collapsing Units
You can expand and collapse units in the Echelon View on the Objects List Panel.
To expand a unit in the Echelon View, click the plus sign next to its icon.
To collapse a unit in the Echelon View, click the minus sign next to its icon.
Individual entities are directly subordinate to the force they belong to. If a simulation object becomes part of a unit, the unit is subordinate to the force and the individual entity is one level further away. Seen another way, you can say that the force is the parent and all other simulation objects in that force are children, grandchildren, and so on.
The Echelon View displays the simulation objects in columns that are equivalent to their relationship to the force – the first column is children, the second column is grandchildren, and so on.
At the top of each column in the Echelon View is a plus (+) or minus (-) button that works like the buttons within the hierarchical display (Figure 25-2). A plus indicates that at least one simulation object in that column is a unit and that none of the units in the column are expanded. A minus indicates that at least one unit at that level is expanded. Clicking a minus sign collapses all units in the column. Clicking a plus sign expands all units in the column.
To change the hierarchical level view in the Echelon View, click the level controls in the horizontal band across the top of the window.
Figure 25-2 illustrates an Echelon View with several levels of units, some of which are collapsed and some of which are expanded.
If you want to select units, you need to collapse them so that you can select the unit icon. However, when you do this, you can no longer see where individual subordinate simulation objects are located and if subordinates are destroyed, you cannot see which ones are destroyed and which are functional. VR-Forces provides the following options for displaying unit icons so that you can work with them in a way that best meets your visualization and simulation object management needs:
Display ghosted icons for hidden simulation objects.
Allow ghosted icons to be selected.
Display all unit members.
Manually expand and collapse the display.
Display leaf-level unit members.
2D 3D
Displaying Units — Displaying Ghosted Icons
To configure the display of unit icons:
Choose Settings Display. The Display Settings dialog box opens.
Select the Unit Display Settings page (Figure 25-4).
To display unit members based on the current level of aggregation only, clear Show Ghosted.
To display ghosted icons:
In the To Echelon Level box, select the level of aggregation to show ghosted icons for. To show all levels without needing to consider how many levels there are, select All. Figure 25-5 illustrates the effect of changing the echelon level for displaying ghosted icons for the VR-Forces unit hierarchy shown.
To allow selection of ghosted icons (2D view only), select Allow Selection of Ghosted Icons. (In 3D views, you can always select entities at the leaf level.)
Level 1
Level 2
Level 3
Level 1
Level 2 Level 3
Figure 25-5. Displaying ghosted icons by echelon level
VR-Forces lets you configure when to display unit icons and bounding volumes. Bounding volumes are translucent polygons that show the extents of the unit. This is useful when the individual entity icons or models are not displayed. You can configure icons and bounding volumes as follows:
Enable and disable the display of units. When disabled, only the 2D icons or 3D models for leaf level unit members are displayed.
Enable and disable the display of bounding volumes. Bounding volumes are displayed only for collapsed units. You can restrict the display of bounding volumes to the selected units.
In 3D observer modes, enable or disable the display of unit icons.
Figure 25-6 shows a unit bounding volume in Stealth observer mode, with leaf nodes displayed.
Figure 25-6. 3D bounding volume
Figure 25-7 shows a unit bounding volume in Plan View observer mode, with ghosting enabled.
Figure 25-7. 2D bounding volume
You can display unit icons without showing bounding volumes and vice versa.
To configure the display of unit icons and bounding volumes:
Choose Settings Display. The Display Settings dialog box opens.
To enable the display of unit icons, bounding volumes, or both, select Show Units.
To display bounding volumes for collapsed units, select Show Bounding Volumes.
To restrict the display of bounding volumes to the selected units, select Show Bounding Volumes Only for Selected Units.
To display unit icons in 3D observer modes, select Show Aggregate Icon (3D Only).
You can also enable and disable units by choosing Settings Units or by selecting the Units button ( ) on the Display Settings Toolbar.
Unit bounding volumes can be displayed using primary colors or MIL-STD colors.
To specify the color scheme to use for unit bounding volumes:
Choose Settings Display. The Display Settings dialog box opens.
Select the Force Coloring Settings option that you want (Use Primary Colors or Use MIL-STD Icon Colors).
This section describes tasks, set data requests, and scripted tasks and sets.
Some tasks are mutually exclusive with other tasks, for example, a simulation object cannot execute two different movement tasks at the same time. Other tasks, such as Send Text Message, can run concurrently with movement tasks. When you task a simu- lation object, if the new task is mutually exclusive with the current task, the simulation object immediately stops the current task and begins the new one. If the new task is not mutually exclusive with the current task, the simulation object executes the new task and continues with the previous task. For information about how to configure mutually exclusive tasks, please see “Configuring Task Execution Rules,” on page 26-35.
If a simulation object has a plan, when you give it an independent task, it abandons the rest of the plan.
Independent tasks are useful for assigning tasks to simulation objects without the need to edit a plan. You can assign them interactively, so simulation participants can respond immediately to events in a simulation by assigning new tasks to a simulation object as they might have to do in the field. General issues for assigning tasks are described in detail in Chapter 26, Assigning Tasks. Specific task procedures are in the succeeding chapters.
Many tasks are implemented as part of the VR-Forces code (C++ tasks) and cannot be added to or changed by end-users. Other tasks, called scripted tasks, are implemented using Lua scripts. You can edit scripted tasks and write new ones. For details, please see “Creating Scripted Tasks and Sets,” on page 32-1.
VR-Forces Users Guide
Section V - Tasks and Sets
V-1
Tasks and Sets — Introduction to Set Data Requests
VR-Forces has a special type of scripted task, called a reactive task, that does not get explicitly assigned to simulation objects. Reactive tasks monitor the simulation and run only if certain conditions are met. For information about reactive tasks, please see “Reactive Tasks,” on page 26-12.
A third type of scripted task is the background process. Background processes run continuously to handle certain types of ongoing aggregate-level activities, such as consuming or receiving supplies, calculating a unit’s footprint, and automatically attacking opposing forces. For information about background processes, please see “Background Processes,” on page 33-30.
Figure 25-1 illustrates the many ways that a simulation object can have its task, behavior, and state changed.
Reactive task
Plan
Set data request
Simulation Object
Innate behavior
Independent task
Global command Tasked by superior
Figure 25-1. Inputs to simulation object actions
You can create new set data requests using the same Lua scripting process that you can use to create scripted tasks.
Section V - Tasks and Sets
V-2 VT MAK
This chapter provides general details about how to assign tasks to simulation objects. For descriptions of specific tasks and how to assign them, please see Chapter 30, Embarkation, Wait, Radio, and Other Tasks and Chapter 31, Tasks for Aggregate-Level Scenarios.
Assigning Tasks to Simulation Objects 26-3
C++ Tasks and Scripted Tasks 26-4
Concurrent Task Execution 26-5
How do I Know which Simulation Object can Execute a Task? 26-7
Escaping the Task Assignment Process 26-7
Specifying Parameters for Tasks 26-7
Filtering the Object Selection Lists 26-10
Skipping (Stopping) a Task 26-10
Assigning Tasks to Units 26-11
Independently Tasking Unit Members 26-12
Disabling Reactive Tasks 26-15
Setting the Priority of a Reactive Task 26-16
Canceling a Reactive Task 26-18
Using Behavior Sets to Manage Scripts 26-19
Assigning Tasks
Assigning a Behavior Set to a Force 26-21
Entity Movement On Roads and Off Roads 26-22
Fixed-Wing Entity Tasks and Behaviors 26-23
Placement of Newly Created Fixed-Wing Entities 26-23
Fly Task Behavior is Different from Move Task Behavior 26-24
Specifying and Maintaining Altitude for Fixed-Wing Entities 26-25
Fixed-Wing Entity Movement on the Ground and in the Air 26-26
How Fixed-Wing Entities Take Off 26-28
How Fixed-Wing Entities Land 26-29
Rotary-Wing Entity Tasks and Behaviors 26-30
Controlling Rotary-Wing Orientation 26-32
Configuring Suppression Effects 26-34
Configuring Task Execution Rules 26-35
Configuring Action Categories 26-36
You can assign tasks to a simulation object as part of its plan, as part of a global plan, and independently of any plan. For conceptual information about tasks, please see “Introduction to Tasks,” on page 25-1. For information about how to add a task to a plan, please see “Adding a Task or Set Data Request to a Plan,” on page 36-4.
You cannot assign tasks to non-VR-Forces simulation objects. However, you can use a remote simulation object as a parameter in a task, for example, following a remote simulation object, or targeting a remote simulation object. For more information, please see “Using Non-VR-Forces Simulation Objects in Plans,” on page 35-19.
For the procedures for assigning tasks, please see Chapter 27, Movement Tasks for Entity- Level Scenarios, Chapter 28, Engagement Tasks for Entity-Level Scenarios, Chapter 29, Human and Crowd Tasks, Chapter 30, Embarkation, Wait, Radio, and Other Tasks and Chapter 31, Tasks for Aggregate-Level Scenarios.
If your installation uses the VR-Forces API to add additional tasks, consult with your software engineers for procedural information. Please see “Fixed-Wing Entity Tasks and Behaviors,” on page 26-23 and “Rotary-Wing Entity Tasks and Behaviors,” on
page 26-30, for additional information about assigning tasks to these simulation object types.
The instructions for creating tasks direct you to use options on the Task menu. However, all the options available on the main menu are also available on context-sensi- tive menus. A limited number of tasks are available on the Tasks Toolbar and on the Last Selected Object Panel.
The VR-Forces application includes a basic set of tasks for movement, weapons fire, and other actions, that were developed using the VR-Forces Toolkit and the C++ API. System integrators often use the C++ API to add additional tasks before delivering VR- Forces to their customers. These tasks are called C++ tasks to distinguish them from another type of task – the scripted task. Scripted tasks, written in the Lua programming language, use the lower-level C++ tasks and the VR-Forces Lua API to build higher- order tasks for simulation objects. You do not need the VR-Forces Toolkit or a devel- opers license to write scripted tasks.
To the VR-Forces end user, scripted tasks, most of which are listed on the Task menu, are indistinguishable from C++ tasks. For information about scripted tasks, please see Chapter 32, Creating Scripted Tasks and Sets.
VR-Forces also supports two special categories of scripted tasks called reactive tasks and background processes. These tasks are not on the Task menu. Reactive tasks execute when a condition becomes true. For details, please see “Reactive Tasks,” on page 26-12. Background processes run continuously. They only apply to aggregate-level scenarios. (For details, please see “Background Process List,” on page 31-32.)
Some tasks can execute at the same time. Some are mutually exclusive. If you assign a simulation object a task that is mutually exclusive with its current task, the current task is abandoned. If you assign a task that is not mutually exclusive with the current task, it executes the new task while continuing to execute the previous task.
When you assign a mutually exclusive independent task, VR-Forces displays a prompt that asks you to confirm interruption of the current task. You can disable this prompt if you always want a new task to interrupt the current task. For details, please see “Enabling and Disabling the Task Confirmation Prompt,” on page 26-6.
C++ tasks are organized into the following groups:
Weapon
Movement
Radio
Depth control.
All tasks within a group are mutually exclusive among themselves. For example, all movement tasks are mutually exclusive. Simulation objects that are moving can usually execute a task from one of the other groups at the same time. For example, simulation objects can execute the various Send tasks while they are executing movement tasks.
When you create a scripted task, you can specify which groups it conflicts with. For information about how to configure mutually exclusive tasks, please see “Configuring Task Execution Rules,” on page 26-35. For information about scripted tasks, please see Chapter 32, Creating Scripted Tasks and Sets. For information about how to use concur- rent tasks in plans, please see “Using Concurrent Tasks in Plans,” on page 35-18.
To enable or disable the task override confirmation prompt:
Choose Settings Display. The Display Settings dialog box opens.
Select the Entity Display Settings page (Figure 26-1).
To enable or disable the prompt for interrupting a task, select or clear the Prompt Before Interrupting Task check box.
To enable or disable the prompt for abandoning a plan, select or clear the Prompt Before Abandoning Plan check box.
Simulation objects can execute tasks for which they have an appropriate controller. They access most task controllers through systems. Therefore, simulation objects can execute the tasks supported by their various movement, weapon, sensor, and other systems. For example, to deploy naval mines, an entity needs a Naval Mine Deploy- ment system.
To see which systems a simulation object has, and thereby infer which tasks it can execute, you can examine the simulation object’s systems in the Simulation Object Editor. You can also refer to VR-Forces Entity Model Catalog, which lists the systems for each simulation object configured in the Simulation Object Editor. Appendix D, Systems and System Usage lists each system provided with VR-Forces, the types of simu- lation objects it supports, and its description. It also lists each system and the simula- tion objects that are configured to use it.
You can escape the task assignment process at any point before you complete it.
To escape the task assignment process, in the task dialog box, click Cancel.
If you select the appropriate object, the selection is reflected in the task dialog box.
If you prefer, you can specify all parameters in the task dialog box. Depending on the zoom level of the terrain and the number of simulation objects and tactical graphics you have created, it may be easier to select an object from a list than to select it from a densely packed group of icons.
Figure 26-2. Multiple list dialog box
The active list is determined as follows:
When you first open the dialog box, the first list window is automatically active. If you select an object in the display, it is selected in the first list window. Then the second list window automatically becomes active and the next object you select in the display is selected in the second list window. This sequence continues until all list windows have a selection. Then the last window stays as the active list.
Selecting an object in a list window makes it active.
Clicking the Filter button 
) next to the Filter list makes that list window active. It will stay active until you click the button to inactivate it or click in another list window.
If all lists are inactive (by clicking the Filter button to put it into the unselected state), you can click objects in the display without affecting the selections in the list windows.
The Information dialog box for a simulation object lists its current task on the Tasks page. It also lists the state of the reactive tasks that are enabled for the simulation object. If a simulation object is executing a task as part of its plan, you can see which task it is executing by opening its Plan window (Figure 26-3). You can also see the current task on the Last Selected Object Panel and the Tasks page of the Information dialog box.
Figure 26-3. Display of simulation object task status
If a task requires you to select objects, you can filter the object selection list to make it easier to find the particular objects you need to select (Figure 26-4). If you are selecting simulation objects, for example in a Follow Entity task, you can display all simulation objects, individual simulation objects only, or units only. Within the latter two groups, you can display friendly or opposing simulation objects. In a Move To task, you can filter for waypoints, friendly simulation objects, or opposing simulation objects.
Figure 26-4. Simulation object filter list
To filter a simulation object list, in a task or set data request dialog box, choose the filter type from the list.
To order a simulation object to skip a task, choose Objects Skip Task.
Skip Task does not apply to members of a unit that are executing tasks assigned to them by the unit leader.
You can also stop tasks from the Task Status page of the Information dialog box. For details, please see “Canceling a Reactive Task,” on page 26-18.
Assigning Tasks — Assigning Tasks to Units
To assign a task to a unit, select the unit, then assign it a task as you would any individual entity.
VR-Forces has two tasks for moving in convoys – Convoy Along and Convoy To. These tasks can only be assigned to units made up of ground vehicles. When a unit receives a convoy task, it organizes itself into a column based on the echelon IDs. Then it executes the task.
Once the task begins, the members of the unit try to maintain a consistent distance apart from each other. You can configure this distance by editing the Ground Convoy Movement system in the OPD Editor. The distance is specified by the separation- distance parameter. You can also specify an amount by which the separation distance can vary using the separation-tolerance parameter.
If VR-Forces can determine that a convoy task is not appropriate for a given unit, for example a rotary wing unit, the convoy tasks are not available on the Task menu. However, in other cases, such as mixed units or if you aggregate disparate entities as Ground Unit, it is up to you to know whether or not a unit consists only of ground vehicles or contains platforms that do not support convoy tasks.
Members of a disaggregated unit can have individual plans or be assigned tasks inde- pendently of the unit. If a member of a unit is independently tasked, when it completes its task it automatically becomes tasked by its superior. You do not need to give it a Tasked by Superior set data request. You can override this behavior by setting an object’s tasked-by-superior-upon-task-complete parameter in the object parameter database to False.
If a Skip Task command is given to an independently tasked subordinate, it remains in the independently tasked state until it either completes a task or it is given a Set Tasked by Superior set data request.
When a simulation object becomes tasked by its superior, it does not execute the task that the unit is currently executing. It receives the next task that is sent out by the unit.
When a disaggregated unit changes to the aggregated state, the individual subordinates cease to exist. Therefore, if a subordinate is executing an independent task, when the unit changes state, the task activity ends immediately.
Reactive tasks are a special category of scripted tasks. Unlike other tasks (whether scripted or C++), reactive tasks do not begin to execute as soon as they are assigned. They monitor events in a simulation and execute in response to conditions specified in the script. In this way they are similar to collision avoidance, which takes over entity movement in response to an imminent collision, or trigger statements in plans, which get triggered when a condition becomes true.
Because reactive tasks are scripted tasks, you are not restricted to the few conditions available in plans. You have the full VR-Forces Lua API available to script the condi- tions and the resulting behaviors. Like other scripted tasks, reactive tasks are either scenario-specific or system reactive tasks.
Reactive tasks have the following behaviors and characteristics:
Reactive tasks can be automatically enabled for a category of simulation object. They can also be individually enabled and disabled.
When a reactive task is activated, the current task is suspended. When the reactive task concludes, the simulation object resumes the previous task, if possible. There may be cases where the previous task is no longer meaningful due to changes in the scenario.
Reactive tasks support task concurrency.
Reactive tasks can be interrupted by other reactive tasks. Precedence among reactive tasks is based on a task’s priority. If a reactive task is executing and a reactive task with a higher priority gets triggered, it suspends the current reactive task. When the higher priority task completes, the lower priority task resumes. When it completes, the original task resumes. Multiple nesting of tasks in this way is permitted. Reac- tive tasks with the same or lower priority do not interrupt the active task.
Reactive tasks can have parameters, just like any other task. If a reactive task is enabled and the parameters are not set, it may not work as expected. A well-written reactive task should have default values for parameters, but VR-Forces does not enforce this.
Users can change the priority of a reactive task while a scenario is running. This affects the next activation of the task.
If a reactive task is interrupted by a non-concurrent independent task assignment, from the Task menu or a global plan, the reactive task and all suspended tasks are canceled and the new task is executed. However, it is still possible that the new task could be interrupted by the same or a different reactive task.
Active reactive tasks can be canceled by a VR-Forces user.
After a reactive task is complete, it enters the enabled state and can become trig- gered again.
The status of a reactive task is displayed on the Task Status page of the Information dialog box, along with the status of the current or suspended task.
The following sections describe how to manage reactive tasks in a scenario. For infor- mation about how to write and configure reactive tasks, please see Chapter 33, Writing Scripts.
This procedure applies to the currently selected simulation object. If you have multiple Information windows open, selecting a reactive task on the Task Status page of a simulation object does not select the simulation object and does not make it the task affected by this procedure.
To enable a reactive task:
Select the simulation object for which you want to enable the task.
Choose Set Reactive Tasks Enable. The Enable Reactive Task dialog box opens (Figure 26-5). If there are no reactive tasks available, the dialog box states this. This condition occurs if all appropriate reactive tasks are already enabled or there are no reactive tasks for this entity type.
In the Reactive Tasks list, select the task you want to enable. If the task requires parameters, the dialog box redisplays and lists the parameters.
If necessary, specify the parameters.
Click OK.
You can also enable reactive tasks in the Manage Reactive Tasks dialog box. For details, please see “Managing Reactive Tasks,” on page 26-17.
You can disable reactive tasks on a per-simulation object basis. When you disable a reac- tive task, any active tasks continue to execute. However, no new instances of the disabled task will be activated.
This procedure applies to the currently selected simulation object. If you have multiple Information windows open, selecting a reactive task on the Task Status page of a simulation object does not select the simulation object and does not make it the task affected by this procedure.
To disable a reactive task for a simulation object:
Select the simulation object for which you want to disable a reactive task.
Choose Set Reactive Tasks Disable. The Disable Reactive Task dialog box opens. If there are no reactive tasks available, the dialog box states this. This condi- tion occurs if all appropriate reactive tasks are already disabled or there are no reac- tive tasks for this simulation object type.
In the Reactive Tasks list, select the task you want to disable.
Click OK.
You can also disable reactive tasks in the Manage Reactive Tasks dialog box. For details, please see “Managing Reactive Tasks,” on page 26-17.
When a reactive task is created, it is assigned a priority. The priority determines which reactive tasks it can override or be overridden by. Priorities are expressed as integers, with 1 being the highest priority. You can change the priority of a reactive task on a per- simulation object basis.
This procedure applies to the currently selected simulation object. If you have multiple Information windows open, selecting a reactive task on the Task Status page of a simulation object does not select the simulation object and does not make it the task affected by this procedure.
To change the priority of a reactive task:
Select the simulation object for which you want to change a reactive task’s priority.
Choose Set Reactive Tasks Priority. The Reactive Task Priority dialog box opens. If there are no reactive tasks available, the dialog box states this.
In the Reactive Tasks list, select the task whose priority you want to change.
Select a priority in the box. The lower the number, the higher its priority.
Click OK.
You can also change priority in the Manage Reactive Tasks dialog box. For details, please see “Managing Reactive Tasks,” on page 26-17.
You can enable, disable, and change priority for all the reactive tasks that apply to a simulation object from the Manage Reactive Task dialog box.
To manage multiple reactive tasks for a simulation object:
Select the simulation object for which you want to manage reactive tasks.
Choose Set Reactive Tasks Manage or choose Objects Manage Reactive Tasks. The Manage Reactive Task dialog box opens (Figure 26-6). It lists each reac- tive task configured for this simulation object type, its status, and its priority. If a task requires parameters, you can set them.
For each task, to enable or disable, select an option from the list in the Enabled column.
For each task, change the priority by selecting an option in the box in the Priority column.
For each task that has parameters, click Parameters and set its parameters. (A task must be enabled to set its parameters.)
Click OK.
You can cancel a reactive task while it is executing. When you cancel a reactive task, the simulation object resumes the suspended task. However, if the condition that caused the reactive task to activate is still true, when you cancel a reactive task, it will usually immediately activate again.
i You can also use this procedure to cancel (skip) a regular task.
To cancel a reactive task:
Select the simulation object whose task you want to cancel.
Choose Objects Information, or press i. The Information dialog box opens.
Select the Task Status page. If a reactive task is active, it has a button in the Cancel column (Figure 26-7).
Right-click the active task and choose Cancel Reactive Task, or click the button in the Cancel column.
Behavior Sets let you organize scripts so that a set of related tasks and set data requests can be enabled or disabled at the force level.
If a script is not assigned to a Behavior Set, its availability to a simulation object is determined by the following settings:
The Valid for Entity Types list for the script.
For tasks specific to systems, configuration of that system on a simulation object.
For reactive tasks, the Enable/Disable setting in the Manage Reactive Tasks dialog box for the simulation object.
If a script is assigned to a Behavior Set, then in addition to the requirements in the previous list, it is available to simulation objects only if the Behavior Set is assigned to a force and only to simulation objects of that force. (You can assign a Behavior Set to more than one force.)
As an example of how you might use Behavior Sets, suppose that dismounted infantry react differently to an attack depending on whether they are operating in rural terrain or in urban terrain. You have a set of scripted tasks that you have written for reacting to attack in each of these two situations. If you are not using Behavior Sets, then to manage which tasks would get used when the simulation objects are under attack, you might use one of the following strategies:
Tell users not to use the inappropriate tasks.
Enable and disable the correct set of tasks in the Scripts dialog box before the start of the scenario.
Enable and disable the tasks on a per simulation object basis in the Manage Reac- tive Tasks dialog box.
Shifting back and forth between simulations in different terrains might become a management problem.
Using Behavior Sets, you could:
Create a Behavior Set for rural terrain operations and one for urban operations.
Assign the relevant scripts to each Behavior Set.
Before you run a scenario, you would assign the Behavior Set you want to use to the force.
The tasks in the Behavior Set would be enabled and those in the unused Behavior Set would be disabled. There would be no further configuration required.
Assigning Tasks — Using Behavior Sets to Manage Scripts
To create a Behavior Set:
Choose Simulation Behavior Sets. The Edit Behavior Sets dialog box opens (Figure 26-8).
Figure 26-8. Edit Behavior Sets dialog box
Click the Add button ( ). The New Behavior Set Name dialog box opens.
Type a name for the Behavior Set.
Click OK.
In the Scripts list, select the scripts that you want to assign to this Behavior Set. Click the left-facing arrow. The scripts are added to the Behavior Set. If you select a folder, all tasks in the folder get added to the Behavior Set. (You can also assign tasks to Behavior Sets in the Edit Script dialog box. For details, please see “Creating a New Script,” on page 32-6.)
Optionally, assign the Behavior Set to a force.
You can edit Behavior Sets, rename them, and delete them.
To edit Behavior Sets:
Choose Simulation Behavior Sets. The Edit Behavior Sets dialog box opens (Figure 26-8).
Expand the Behavior Set that you want to edit.
Add and remove scripts by selecting them and clicking the appropriate arrow button.
To rename a Behavior Set, select it in the Behavior Sets list, click the Rename button ( ), and type a new name.
To delete a Behavior Set, select it in the Behavior Sets list and click the Delete button ( ).
You can only assign one Behavior Set to a force at any given time.
To assign a Behavior Set to a force:
Choose Simulation Behavior Sets. The Edit Behavior Sets dialog box opens (Figure 26-8).
In the Assign Behavior Set to Force window, click the list for the force to which you want to assign a Behavior Set.
Select the Behavior Set that you want to assign. If you do not want any Behavior Sets assigned, select the blank line in the list.
Assigning Tasks — Entity Movement On Roads and Off Roads
Some terrains have vector road networks. Ground vehicles can use these networks to move precisely through the terrain. The tasks for moving on roads are distinct from the tasks for moving without respect to road networks. (For a description of how entities move when they use road driving, please see “Road Driving Behavior,” on page 26-23.) If you want entities to move both on and off roads, you need to understand how these tasks interact.
The road driving tasks are Move to Waypoint (Plan Along Roads) and Move to Loca- tion (Plan Along Roads). The generic movement tasks are Move to Location and Move to Waypoint.
!
!
Road driving tasks are valid only for ground vehicles. If you give a road driving task (including Move To (Plan Along Roads), Treat Route as Road, and Use Roads in pattern of life default plans) to any other type of entity, it will fail.
When you give a simulation object a generic Move To task, it moves directly towards its destination. If navigation data is available, it plans a path using that data. If no naviga- tion data is available, the entity avoids obstacles, but otherwise does not pay attention to the terrain except to the extent that it cannot move on certain soil types or terrains that are too steep.
When you give an entity a Plan Along Roads task, it looks for a road network. If it finds one:
It moves to the nearest point on the road.
It moves along the road network to the nearest point to the final destination.
It moves to the final destination.
The road driving feature in VR-Forces requires that the road vectors making the network be connected at their edges. If your terrain’s data does not have accurate positions for road ends, which causes them to be disconnected, VR- Forces may not be able to plan a path along those roads.
It clamps to the road and does not deviate from it.
It goes around corners accurately.
It ignores any obstacles that are near to the road and which would ordinarily trigger obstacle avoidance. The vehicle only responds to obstacles that block the road.
If a vehicle is blocking its progress and there is an adjacent lane in the road that is clear, the entity passes the blocking vehicle.
In the Move Along Route task, you can specify that VR-Forces treat the route as a road. The entity would then use the road driving system to follow the route.
This section describes the behaviors of fixed-wing entities supplied with VR-Forces and the issues you should keep in mind when assigning tasks and set data requests.
When you create a fixed-wing entity, it is placed on the ground. If you want a fixed- wing entity to start a scenario in the air, you must set its altitude at the beginning of the scenario. It will loiter at the specified altitude.
Fixed-wing entities can move in response to Fly tasks (Fly Altitude, Fly Heading, and so on) and Move tasks (Move to Waypoint, Move Along Route, and so on). There are important differences between how fixed-wing entities respond to the different classes of movement tasks. Fixed-wing entities can move on the ground (taxi), in which case they move like ground vehicles.
For Move and Patrol tasks, if a fixed-wing entity is in the air:
When a fixed-wing entity moves to a point or between the vertices in a route, it immediately ascends or descends to the altitude of the target point. This is illus- trated in “Fixed-Wing Movement Between Vertices,” on page 26-27.
When an entity arrives at a point or the end point of a route, it loiters.
Fly tasks are only for entities that are in the air. You cannot use them to cause an entity to take off or land. For Fly tasks:
Entities move to a new altitude at the specified heading, at the specified climb or descent rate.
When they reach the new altitude, they continue flying at their current heading.
Given these differences, if you want to change heading, altitude, or both for an entity that is in the air and not executing a Move or Patrol task, use a Fly task. These tasks are not designed to have an entity move to a particular location or along a route. To have an entity move to a particular location or along a route, use a Move or Patrol task. In most cases, Fly Altitude will be preferable to Move to Altitude.
You can explicitly change a fixed-wing entity’s altitude in the following ways:
The Altitude set data request moves an entity immediately to the specified altitude.
The Move to Altitude task causes an entity to spiral to the specified altitude at the same coordinates that it had when it received the task.
The Fly Altitude and Fly Heading and Altitude tasks cause the entity to move smoothly to the new altitude while continuing to fly at its current or newly speci- fied heading.
An entity’s altitude changes implicitly if it is given a Move or Patrol task in which the altitude of the target point or vertex is different from the entity’s current altitude. In this case the entity immediately moves to the new altitude and then proceeds to the target point.
When you assign a task that includes a location and you specify the location by clicking on the terrain, the default altitude is zero. If you do not specify a non-zero altitude in the task dialog box, VR-Forces uses the altitude of the entity at the time the task is assigned. This prevents you from inadvertently specifying a location that would cause the entity to crash.
Fixed-wing aircraft support takeoff and landing. Since they can move on the ground and in the air, you need to understand their behavior in these different environments. Table 26-1 and Table 26-2 describe how fixed-wing entities respond to Move To, Move Along Route, and Patrol Route tasks depending on their current location. The rest of this section provides additional details about take-off and landing.
If entity is on/in the: | and waypoint is on/in the: | the entity: |
Ground | Ground | taxis to point. |
Ground | Air | takes off towards the point. |
Air | Air | flies to point. |
Air | Ground | crashes. |
If entity is on/in the: | and next vertex is on/in the: | the entity: |
Ground | Ground | taxis to vertex. |
Ground | Air | takes off toward the vertex. |
Air | Air | flies to the vertex. |
Air | Ground | tries to land at the vertex. |
Fixed-wing entities do not support terrain-following. Therefore, when you task a fixed- wing entity to move to a point or follow a route, you must be certain that there are no points in the terrain that are higher than the altitude of the entity’s flight path, or the entity will crash. For example, if you assign a fixed-wing entity to follow a route whose vertices are set at 3000 meters above sea level, if the terrain rises above 3000 meters at some point in between two vertices of the route, the entity will crash into the terrain at that point (Figure 26-9). You can view the terrain profile of the route to check for inter- sections with the terrain. (For details, please see “Displaying a Line’s Terrain Profile,” on page 54-3.)
Trajectory
Route
Figure 26-9. Fixed-wing route following
If two vertices in a route are not at the same altitude, a fixed-wing entity does not fly from the first vertex to the second in a smooth gradient. As soon as it passes the first vertex, it immediately descends to the altitude of the next vertex and then continues to fly towards it at that altitude. Therefore, it is possible that you could create a route that does not intersect the terrain, but an entity flying along that route could crash because a location in the terrain exceeds the altitude of a destination point, as illustrated in Figure 26-10.
Route
Intended Flight path
Terrain profile
Figure 26-10. Fixed-wing trajectory between vertices
If you want a plane to change altitude using a smooth gradient, use one of the Fly Altitude tasks. However, these tasks do not let you follow a route.
You can have fixed-wing aircraft take off using the Fixed Wing Takeoff task (for details, please see “Fixed Wing Takeoff,” on page 27-8) or by using innate behavior. This section describes take-off using innate behavior.
Fixed-wing entities take off by moving to a waypoint that is above ground level or by following a route that has a vertex above ground level.
When you task a fixed-wing entity to move to a waypoint that is above ground level, the entity orients itself directly towards that point and accelerates in the direction of the point. When it reaches its minimum lift speed, it takes off and rises to the altitude of the point it is moving to. You can control the distance required to take off by setting the max-thrust parameter.
When a fixed-wing entity takes off, it does not take into account the soil type or terrain, except that if the slope of the terrain along which the entity must move to take off is greater than the max-slope parameter, the entity halts.
Fixed-wing entities do not know anything about runways that may be part of a terrain database. When you create a waypoint towards which an entity will take off, or create a route along which an entity will take off, you are responsible for ensuring that the entity is properly oriented towards the runway.
If an entity takes off as part of route following, you can define a runway with two points on the ground. If an entity detects that the point in the route after the one it is moving towards is in the air, it uses the current point as the take-off direction, but takes off as soon as possible and flies to the point in the air. Figure 26-11 illustrates this behavior.
Vertex determines take-off heading (Z= 0 m) Z=1000 m
Heading after take-off
Heading during take-off
Take-off point
Figure 26-11. Defining a runway for take-off
You can have aircraft land using the Fixed Wing Land task (please see “Fixed-Wing Land,” on page 27-7), or as described in this section. The underlying behavior of the Fixed Wing Land task is the same as in this section. Using the Fixed Wing Land task automates the process of setting up the approach route.
A fixed-wing entity can land only in the context of following or patrolling a route. When a fixed-wing entity follows a route and determines that the next vertex in the route is on the ground, it decelerates as it reduces altitude towards that vertex. If it does not have enough distance from the previous vertex to decelerate sufficiently, it may crash. To ensure adequate deceleration, you may want to create a trigger that sets the entity’s speed when it approaches the runway.
Any time an entity is within 10 meters of the terrain and it is moving within 10 percent of its minimum lift speed, it will try to land.
To orient an entity for landing, you may have to create several vertices prior to the runway to get the entity properly lined up. Figure 26-11 shows two different routes ending at an airport (the routes have been edited to improve visibility). The first route has vertices that line up the entity with the runway. The second route curves in towards the runway, so the entity does not approach the runway in a straight line. Therefore, as it reaches the landing point, it is not lined up with the runway and it lands on the taxiway.
Assigning Tasks — Rotary-Wing Entity Tasks and Behaviors
Entity lands on runway
Entity lands to left of runway
Figure 26-12. Landing fixed-wing entities
This section describes the behaviors of rotary-wing entities supplied with VR-Forces and the issues you should keep in mind when assigning tasks and set data requests.
Rotary-wing entities get created on the ground unless you specify an altitude at creation. (For details about specifying an altitude when you create an air platform, please see “Specifying an Object’s Altitude,” on page 16-14.)
If a rotary-wing entity is airborne and it is not assigned a task, it hovers at the specified location and altitude. When it completes a task, it hovers in the location where it completed the task.
Assigning Tasks — Rotary-Wing Entity Tasks and Behaviors
The terrain-check parameter determines how a rotary-wing entity interacts with the terrain. If terrain-check is False, a rotary-wing entity ignores the terrain. It could appear to fly below ground. However, when terrain-check is set to False, VR-Forces does not have to check ground points, so performance may improve.
When terrain-check is True, rotary-wing entities interact with the terrain. If a rotary- wing entity approaches a ground point at three meters per second or less, it lands. If it approaches the ground at a greater speed, it crashes.
When you assign a task that includes a location and you specify the loca- tion by clicking on the terrain, the default altitude is zero. If you do not specify a non-zero altitude in the task dialog box, VR-Forces uses the alti- tude of the entity at the time the task is assigned. This prevents you from inadvertently specifying a location that would cause the entity to crash.
Rotary-wing entities are not able to reach moving waypoints or land on moving ships. A rotary-wing entity will approach a given waypoint or landing point, but will never completely reach the goal.
Helicopters have a basic terrain avoidance algorithm that helps prevent crashing if they are sent to waypoints or follow routes that do not have an altitude. The terrain avoid- ance logic maintains a distance above the ground; it does not look ahead. So, a heli- copter could crash if the terrain rises suddenly (Figure 26-13). You can view the terrain profile of the route to check for intersections with the terrain. (For details, please see “Displaying a Line’s Terrain Profile,” on page 54-3.)
Rotary-wing aircraft take wind resistance and the weight of the aircraft, including the weight of any embarked objects, into account when calculating fuel consumption.
Figure 26-13. Helicopter terrain avoidance
If the current speed is greater than the speed specified by vel-to-align-actual.
If the speed of the entity is not greater than vel-to-align-actual, but the desired speed of the entity (the velocity it is attempting to achieve as a result of position or velocity commands) is greater than vel-to-align-desired.
If you do not want a rotary-wing entity to align itself with its direction of travel, set vel- to-align-actual and vel-to-align-desired to speeds that are greater than the speed at which you expect the entity to travel. You can set these parameters in the OPD Editor.
VR-Forces has two suppressive fire tasks.
The Provide Suppressive Fire task tells an entity to fire at a point, along a line, or in an area, one meter above the terrain.
The Provide Suppressive Fire on Location task tells an entity to fire at a location, one meter above the location.
Suppressive fire is executed even if line of sight is blocked near the target location, so you can place the target in a building and get fire on the wall in front of it.
Suppressive fire insults on an entity are accumulated as part of the internal state of the entity. This suppression value also continually decays over time. Therefore large insults, or many small insults in a short time, raises the suppression value, but the value natu- rally drops back down to its starting level.
An entity is considered suppressed when its suppression value rises above a certain threshold. The entity is no longer suppressed when its decaying suppression value falls below a different, lower threshold. This hysteresis allows the model to produce a delay in suppression recovery and at the same time continue handling new insults.
The model represents three suppression levels (in addition to “not suppressed”) so that behavior can be changed for more severe suppression. The number of suppression levels was chosen arbitrarily. Higher levels of suppression are reached when the suppression value passes higher thresholds. The State Data page in the Information dialog box displays the suppression level of the entity, a value between 0 and 3.
Assigning Tasks — Suppressive Fire Tasks
Suppressive fire causes humans that are near the detonation locations to temporarily stop shooting and lose some ability to sense entities. When an entity is suppressed:
Its sensors may have their sensitivity reduced.
Its guns may be prevented from firing.
It may be forced into a crouching posture.
It may be forced to stop moving and go prone. The default configuration for humans is:
Visual sensor sensitivity is reduced to 0.
Guns are disabled.
Level 1 suppression forces a crouch.
Level 2 and 3 suppression stops movement and makes the entity go prone.
The Lifeform Suppression system enables two reactive behaviors. The first one makes the human adopt a crouching posture when it is suppressed. This does not interrupt other movement. The second reaction makes the entity go prone when it is suppressed to level 2 or 3. This interrupts any ongoing movement task. Both reactions restore the original posture when the reaction ends.
Several vehicles are configured so that they cannot fire their machine guns if they are suppressed.
An entity is susceptible to suppression if it has a suppression system. Lifeforms can have a Lifeform Suppression system. Vehicles can have a Vehicle Exposed Crew Suppression system. For details about configuring suppression, please see “Configuring Suppression Effects,” on page 26-34.
Suppression effects are configured by parameters in several components.
The suppression system contains a suppression actuator with several parameters to control its behavior.
suppression-insult-level. The level of insult necessary to suppress the entity, that is, reach the level 1 threshold. This value should be set appropriately for the amount of insult caused by munitions, as defined in the damage-model portion of this descriptor. You can set this parameter in the Simulation Object Editor.
suppression-recovery-time. The time required to recover from the level 1 suppression threshold to a not-suppressed state. This same time is required to recover to level 2 from level 3, and to level 1 from level 2. You can set this parameter in the Simula- tion Object Editor.
passing-rounds-suppress. Determines whether rounds passing by the entity, but not necessarily detonating near it, are considered when detecting insults. You can turn off this effect to save computation time. Default: true.
max-detonation-distance-for-passing-rounds. The maximum distance that the actuator looks for detonations. A line of fire that passes near the entity may detonate some distance beyond the entity. To find such lines, the actuator must look at distant detonations. This may result in the actuator processing many detonations. (The detonation manager makes a distance test for each entity for each detonation, so not much computation is saved by reducing this parameter value.)
hostile-fire-only. If true, the actuator does not consider detonations and passing rounds as insults if they are from a friendly force. Default: true. While the default may be unrealistic in the case of HE shells landing near the entity, it avoids unin- tended suppression when nearby friendly entities are firing at the enemy.
suppression-detonation-insult. The maximum insult that this munition can cause, if it detonates at the entity location or passed directly over the entity.
suppression-detonation-range. The maximum range at which the munition can have effect. The insult from the munition decreases linearly until it is 0 at the maximum range.
In ballistic gun controllers, disabled-by-suppression indicates whether the gun is suscep- tible to suppression. If true, the gun is not allowed to fire while the entity is suppressed. This is true for the handheld weapon systems, but it can also be selectively set for guns on vehicles. For example, tank machine guns are often operated by an exposed crew member, and could be suppressed by small arms fire even if the tank is otherwise unaf- fected by such fire. The handheld systems have this parameter set True, while other machine guns use a variable and so the parameter can be set in the Simulation Object Editor.
Assigning Tasks — Configuring Task Execution Rules
In sensor components, suppression-degrades-sensor-performance-by indicates how they are affected by suppression. It is a value from 0 - 1.0. A value of 0 means that the sensor is not degraded at all by suppression, while a value of 1.0 means that sensitivity is reduced to 0 by suppression. The value can be set in the Simulation Object Editor.
Each simulation object OPE file contains a parameter called task-execution-rules that specifies a task execution rule configuration file. (The default rules file is ./data/simula- tionModelSets/<model_set>/vrfSim/taskRules/default-task-rules.tsk.) The task execution rule file specifies whether or not tasks can be executed concurrently, and if so, which tasks are mutually exclusive.
The task execution rules file has the following parameters:
all-tasks-exclusive. This parameter enables (False) or disables (True) use of concur- rent execution of tasks. When True, the Task Manager executes only one task at a time, and the mutually-exclusive-task-groups parameter is ignored.
mutually-exclusive-task-groups. This parameter is a list of groups. Each group contains a list of tasks that cannot be executed at the same time. Any time a task from a particular group is started by the Task Manager, any currently running task that is part of the same group is interrupted. Tasks that are part of other groups, or not part of any group, are allowed to continue running.
The task names that are listed in the mutually-exclusive-task-groups parameter are the names that are registered with the task factory when a task is added to the system. Groups can contain any number of tasks, and there can be any number of groups.
Tasks are always considered to be mutually exclusive with themselves. For that reason, it is impossible to execute two tasks of the same type at the same time on a single simula- tion object.
default-task-rules.tsk configures the tasks that come with VR-Forces and which were developed in C++. It does not include scripted tasks.
Concurrency for scripted tasks gets set when they are created.
Assigning Tasks — Configuring Task Execution Rules
In scripted tasks, action categories serve the same function as task rules for enforcing concurrency. Action categories are configured in ./data/simulationModel- Sets/<model_set>/vrfSim/taskRules/actionCategories.tsk. An action category is specified with the following entry:
<item>
<first>Movement</first>
<second>
<first>Movement</first>
<second>1</second>
</second>
</item>
If the value in the <first> element matches a group in ./data/simulationModel- Sets/<model_set>/vrfSim/taskRules/default-task-rules.tsk, scripted tasks that use that action category are unioned with the tasks specified in default-task-rules.tsk to form the complete set of mutually exclusive tasks.
If you edit actionCategories.tsk, be sure to update the <count> element to reflect additions or deletions.
27. Movement Tasks for Entity-Level Scenarios
This chapter describes the movement tasks supplied with VR-Forces that apply to entity-level scenarios. Some of these tasks are also used in aggregate-level scenarios. Chapter 29, Human and Crowd Tasks describes some movement tasks that are specific to human characters.
Fly Heading and Altitude 27-10
How Fixed-Wing Entities Follow Entities 27-11
Generate Air Traffic From Flight Plans 27-12
Land at Airport Near Location 27-12
Adding Multiple Move to Location Tasks to a Plan 27-17
Movement Tasks for Entity-Level Scenarios
Move to Location (Plan Along Roads) 27-18
Move to Location (Plan Path) 27-19
Move to Waypoint (Plan Along Roads) 27-21
Move to Waypoint (Plan Path) 27-22
Rotary Wing Airlift Cargo to Location 27-25
Rotary Wing Retrieve Cargo 27-26
Rotary Wing Unload Cargo 27-27
Movement Tasks for Entity-Level Scenarios — Animated Movement
The Animated Movement task lets you assign a scripted behavior to an entity. This task is a generalized version of firing ballistic missiles, which is described in “Ballistic Missiles,” on page 10-8. To use this task, you must first create a file that describes the movements that you want an entity to make. Animated movement files can be in comma-separated values (CSV) format or 3DS ASCII Export (ASE) format. You configure animated movement tasks in the Simulation Object Editor. For details, please see “Configuring Animated Movement,” on page 65-50.
To assign an animated movement task:
Select the entity to task.
Choose Task Movement Animated Movement. The Animated Movement dialog box opens (Figure 27-1).
Optionally, filter the animation list by selecting a category in the Category list.
Select an animation in the Animation list. You are responsible for knowing that the animation is appropriate to the entity you selected.
Optionally, specify a time scale. By changing the time scale you can make the animation run faster or slower than specified in the animation file.
Click OK.
Movement Tasks for Entity-Level Scenarios — Come to Stop
The Come to Stop task stops a surface entity using a normal stop, an emergency stop, or a slow drift.
To assign a Come to Stop task:
Select the entity.
Choose Task Movement Come to Stop. The Come to Stop dialog box opens.
Select an option for how to stop.
Click OK.
i The Convoy Along task is valid only for ground-vehicle aggregates.
For more details about convoys, please see “Convoy Tasks,” on page 26-11.
To assign a Convoy Along task:
Select the unit that you want to send in a convoy.
Choose Task Movement Convoy Along. The Convoy Along dialog box opens.
Specify the route to convoy along.
Click OK.
Movement Tasks for Entity-Level Scenarios — Convoy To
i The Convoy To task is valid only for ground-vehicle aggregates.
For more details about convoys, please see “Convoy Tasks,” on page 26-11.
To assign a Convoy To task:
Select the unit that you want to send in a convoy.
Choose Task Movement Convoy To. The Convoy To dialog box opens.
Specify the waypoint to convoy to.
!
!
When you specify use of roads, VR-Forces looks for roads over a fairly wide area and if one is found, will try to use them even if this results in an indirect approach to the waypoint. If there are no roads close to the route you would expect the unit to take to reach the waypoint, do not select this option.
Click OK.
Movement Tasks for Entity-Level Scenarios — Fast Rope Insertion
The Fast Rope Insertion task causes a helicopter to move to a specified waypoint and disembark a specified number of embarked humans using a fast rope animation. The disembarked humans slide down the rope, then move to a specified muster point and assume a kneeling posture.
This task is available only to helicopters that have the Fast Roping system, such as the MH-60 Black Hawk.
To assign a Fast Rope Insertion task:
Embark human entities on a helicopter that supports the Fast Rope Insertion task.
Select the helicopter.
Choose Task Movement Fast Rope Insertion. The Fast Rope Insertion dialog box opens.
Specify the waypoint at which the insertion should take place.
Specify the altitude at which the helicopter should hover.
Specify the number of humans to be disembarked and inserted.
Specify the waypoint the humans should go to after disembarking.
Click OK.
Movement Tasks for Entity-Level Scenarios — Fixed-Wing Land
“How Fixed-Wing Entities Land,” on page 26-29, describes how fixed-wing entities land and the steps to design a landing approach. The Fixed Wing Land task automates the process of landing a fixed-wing aircraft. However, you must still specify a route to serve as the runway.
When the task is invoked, VR-Forces defines an approach route for the plane to move along. The length of this route is either the plane’s altitude or the length needed to slow the plane down to landing speed, whichever is greater. The route is created and the plane moves along the route, coming to landing speed. At the end of the approach route, the plane is tasked to move along the runway.
!
!
Although it is possible to land an entity on another entity, such as an aircraft carrier, if you want to embark an entity, you must use the Embark task, not a landing task.
To land a fixed-wing aircraft:
Select the entity.
Choose Task Movement Fixed Wing Land. The Fixed Wing Land dialog box opens.
In the Name box, type the name of the route you want it to land on, or select the route in the list or on the terrain.
Click OK.
Movement Tasks for Entity-Level Scenarios — Fixed Wing Takeoff
You can explicitly task a fixed-wing entity to take off. (For details about implicit take- off, please see “How Fixed-Wing Entities Take Off,” on page 26-28.) In a Fixed Wing Takeoff task, the entity moves along the specified route, reaches takeoff speed (30% of minimum lift), and then moves to a point defined by the controller some distance up and away from the end of the route.
To assign a Fixed Wing Takeoff task:
Select the entity.
Choose Task Movement Fixed Wing Takeoff. The Fixed Wing Takeoff dialog box opens.
Select the route to take off on or type its name in the Name box.
Click OK.
You cannot use a Fly Altitude task to cause a fixed-wing entity to take off. A fixed-wing entity that is on the ground ignores this task.
If a rotary-wing entity is on the ground and is given this task, it rises to the specified altitude as it moves forward at its current heading. If a rotary-wing entity is in the air and is given this task with an altitude of zero, it descends to approximately 33 M and continues flying at that altitude at its current heading.
To assign a Fly Altitude task:
Select a fixed-wing or rotary-wing entity.
Choose Task Movement Fly Altitude, or click the Fly Altitude button ( ) on the Last Selected Object Panel or the Tasks Toolbar. The Fly Altitude dialog box opens.
In the Altitude box, specify the altitude above sea level to fly to.
In the Climb/Descent Rate box, specify the rate.
Click OK.
Movement Tasks for Entity-Level Scenarios — Fly Heading
The Fly Heading task commands a fixed-wing or rotary-wing entity to turn to the spec- ified heading at the specified turn rate. It maintains its current altitude and speed.
When it is finished turning to the new heading, it continues to fly at this heading until it receives other commands. The entity will not exceed the turn rate specified in the OPD.
A fixed-wing entity that is on the ground ignores this task.
If a rotary-wing entity is on the ground and is given this task, it rises to approximately 60 M and then drops down to approximately 33 M while simultaneously moving forward and turning to the specified heading. After turning to the new heading, it continues moving forward. Its altitude varies somewhat as it follows the terrain.
To assign a Fly Heading task:
Select a fixed-wing or rotary-wing entity.
Choose Task Movement Fly Heading, or click the Fly Heading button ( ) on the Last Selected Object Panel or the Tasks Toolbar. The Fly Heading dialog box opens.
In the Heading box, specify the heading to fly to.
In the Turn Rate box, specify the rate.
Click OK.
Movement Tasks for Entity-Level Scenarios — Fly Heading and Altitude
The Fly Heading and Altitude task commands a fixed-wing or rotary-wing entity to fly to a specified altitude, at a specified ascent or descent rate, while turning to a specified heading at a specified turn rate. If you do not specify a heading or altitude, the entity continues to use the current value for that parameter.
While executing this task, the entity maintains its current speed. When it completes the command, it continues to fly at the new altitude and heading until given other commands. The entity will not exceed the limits on altitude, turn rate, and ascent/descent rate set in the OPD.
You cannot use a Fly Heading and Altitude task to cause a fixed-wing entity to take off. A fixed-wing entity that is on the ground ignores this task.
If a rotary-wing entity is on the ground and is given this task, it takes off and moves forward while it rises to the specified altitude and turns to the specified heading. If a rotary-wing entity is in the air and is given this task with an altitude of zero, it moves forward and turns to the new heading while it descends to approximately 33 M and continues flying at that altitude on the new heading.
To assign a Fly Heading and Altitude task:
Select a fixed-wing or rotary-wing entity.
Choose Task Movement Fly Heading and Altitude, or click the Fly Heading and Altitude button 
) on the Last Selected Object Panel or the Tasks Toolbar. The Fly Heading and Altitude dialog box opens.
In the Heading box, specify the heading to fly to.
In the Altitude box, specify the altitude above sea level to fly to.
In the Turn Rate box, specify the rate.
In the Climb/Descent Rate box, specify the rate.
Click OK.
Movement Tasks for Entity-Level Scenarios — Follow Entity
You can order an entity to follow a simulation object. You can specify a distance and offset between the simulation objects. If you tell two or more entities to follow the same simulation object, make sure that you do not give them the same offset (please see “Following Simulation Objects,” on page 35-18).
An entity continues to follow its target entity until:
The task is overridden.
The followed entity is destroyed.
If entity A is assigned to follow entity B, but it cannot find entity B, entity A continues to look for entity B until entity B becomes available, or until entity A is assigned another task.
The following entity tries to match the speed of the followed entity unless it has to hold back or catch up to accommodate changes in direction or terrain effects.
To order an entity to follow a simulation object:
Select the entity.
Choose Task Movement Follow Entity. The Follow Entity dialog box opens.
Optionally, filter the entity list.
In the Name box, type the name of the entity to follow, or select it from the list or on the terrain.
Optionally, type an offset in the Behind, Right, and Above text boxes. If you want an entity to follow in front, to the left, or below, put a minus sign (-) in front of the value.
Click OK.
A fixed-wing entity can follow an entity that is on the ground, or might be on the ground, for example if it is following a fixed-wing entity that lands. To ensure that the follower does not crash, make sure that it is following above the followed entity and that the distance above is high enough to account for changes in the terrain.
Movement Tasks for Entity-Level Scenarios — Generate Air Traffic From Flight Plans
When you execute this task, VR-Forces generates routes for flight plans that overlap a specified area of interest. If there are no flight plans in the area of interest, an error message is sent to the Information dialog box for the plan.
To generate air traffic from flight plans:
Create a global plan.
Choose Task Generate Air Traffic From Flight Plans. The Generate Air Traffic from Flight Plans dialog box opens.
In the Maximum Aircraft box, type the maximum number of aircraft you want to have flying at one time. This number only applies to the current task. If you run more than one instance of the task, each task handles the number of aircraft inde- pendently.
To create air traffic along the routes rather than have all the planes start at the beginning of the routes, select the Create Enroute check box.
Select an area of interest. Flight plans that overlap this area get generated.
Click OK.
The Land at Airport Near Location task causes VR-Forces to find an airport near the specified location and land the specified aircraft on an appropriate runway based on the wind direction. This task requires use of a terrain database that has airport and runway data. The ProceduralEarth (online).mtf terrain has airport data.
To land an aircraft at an airport:
Select the entity.
Choose Task Movement Land at Airport Near Location. The Land At Airport Near Location dialog box opens.
Specify the location in the dialog box or on the terrain.
Click OK.
Movement Tasks for Entity-Level Scenarios — Move Along Route
By default, a simulation object moves along a route from its nearest vertex to its end point.
If you edit a route while a simulation object is moving to the starting point of that route as part of a Move Along Route task, the simulation object moves to the nearest vertex, whether it is the starting point, or not.
If a human is moving along a route outside of a navigation area and you move it away from the route or change the route, the entity plans a path to the route vertex it is moving to rather than moving to the nearest point on the route and then proceeding to the target vertex.
If you want a simulation object to repeatedly move along the same route from beginning to end (for example, to follow a circular route), be sure to clear the Start at Closest Vertex check box. If you do not, after the first time the simulation object moves along the route, it will keep going to the end vertex, because that will be the closest vertex to where it is starting the new Move Along Route task.
When you task an air platform entity to follow a route, be sure to take into account the altitude of the route’s vertices and the terrain the entity has to pass over to complete the task. (For more information, please see “Fixed-Wing Movement Between Vertices,” on page 26-27 and “Rotary-Wing Entity Tasks and Behaviors,” on page 26-30.)
Units do not generate subordinate routes until they reach the beginning of the route.
A unit starts moving along a route when the leading edge of its formation is at the first point of the route. It is considered finished when the leading edge reaches the last point of the route.
To direct a simulation object to move along a route:
Select the simulation object.
Choose Task Movement Move Along Route, or click the Move Along Route button ( 
) on the Tasks Toolbar. The Move Along Route dialog box opens.
In the Name box, type the name of the route you want the simulation object to follow, or select a route in the list or on the terrain.
To have a ground vehicle use the road driving movement strategy, select the Treat Route as Road check box. The route is treated as a two-lane bidirectional road.
!
!
If you select Treat Route as Road, the entity must be within 10 meters of the route or the task will fail.
Movement Tasks for Entity-Level Scenarios — Move Into Formation
To have the simulation object start the route at the beginning, clear the Start at Closest Vertex check box.
Click OK.
You can order a disaggregated ground unit to move to a formation at a specified loca- tion. Moving to a formation is not the same as setting formation. Setting formation changes the formation instantly. Moving to a formation causes the members of the unit to travel through the terrain into the new formation.
For aggregated units, Move Into Formation has the same effect as a Formation set data request.
To direct a unit to move to a formation:
Select the unit.
Choose Task Movement Move Into Formation. The Move Into Formation dialog box opens.
Select the desired formation from the list.
Specify the location at which the unit is to move into formation by entering coordi- nates, or by clicking on the terrain.
Specify the heading the unit is to assume at the target location.
Click OK.
Movement Tasks for Entity-Level Scenarios — Move to Depth
You can order an aircraft entity to move to an altitude. When you assign this task, the entity moves to the new altitude at the same coordinates. Fixed-wing aircraft spiral to the new coordinates. Rotary-wing entities rise or descend. Moving to an altitude is not the same as setting altitude. Setting altitude moves an entity instantaneously. It is also not the same thing as Fly Altitude. At the conclusion of Move to Altitude, an aircraft circles or hovers at the new altitude. At the conclusion of Fly Altitude, an aircraft continues moving at its current heading.
Fixed-wing entities that are on the ground cannot respond to a Move to Altitude task. If they are given this task, a message is printed to the object console and the task is ignored.
To send an entity to an altitude:
Select the entity.
Choose Task Movement Move to Altitude, or click the Move to Altitude button ( 
) on the Tasks Toolbar. The Move to Altitude dialog box opens.
Type the altitude that you want the entity to move to.
Click OK.
To assign a move to depth task:
Select the entity.
Choose Task Movement Move to Depth. The Move to Depth dialog box opens.
Select an option for the depth. If you choose a specific depth, type a depth in the Target Depth box.
Specify the ascent/descent rate.
Click OK.
Movement Tasks for Entity-Level Scenarios — Move to Location
If you add Move to Location tasks to a plan, you have more options than when you give an independent task.
Moving to a location is not the same as setting location. Setting location moves a simu- lation object instantaneously. Moving to a location causes a simulation object to travel through the terrain.
If you want a simulation object to use the road network to move to a location, use Move to Location (Plan Along Roads). For details about road movement, please see “Entity Movement On Roads and Off Roads,” on page 26-22.
To direct a simulation object to move to a location:
Select the simulation object.
Choose Task Movement Move to Location, or click the Move to Location button 
) on the Tasks Toolbar. The Move to Location dialog box opens.
Click on the terrain where you want the simulation object to move, or enter the coordinates of the location in the Move to Location dialog box.
Optionally, set the altitude, as described in “Specifying an Object’s Altitude,” on page 16-14.
If you specify the location by clicking and the task is for an air platform that is in the air, be sure to change the altitude to a height that will prevent the entity from crashing.
Click OK.
Movement Tasks for Entity-Level Scenarios — Move to Location
When you add a Move to Location task to a plan, you can add multiple locations without clicking OK and selecting the task again from the menu. Also, since in this method you cannot specify the altitude for each location, you can specify a height above the terrain for the altitude of the succeeding points.
To add multiple Move to Location tasks to a plan:
In the Plan window for a simulation object, choose Task Movement Move to Location. The Move to Location dialog box opens.
Select Each Click Generates A Task.
If you want to specify an altitude for the locations, specify an altitude, as described in “Specifying an Object’s Altitude,” on page 16-14.
Click a point on the terrain for each location that you want the simulation object to move to. A Move to Location task is added to the plan for each location.
Click OK.
Movement Tasks for Entity-Level Scenarios — Move to Location (Plan Along Roads)
When an entity receives this task, it determines if there is a road network near by. If there is, it moves directly to the nearest point on the road network. Then it moves along the roads using road driving behavior until it gets to the point on the road that is closest to the destination. Then the entity moves off the road directly to the destination.
For more information about road driving and how the path planning tasks work, please see “Entity Movement On Roads and Off Roads,” on page 26-22.
To move a ground vehicle to a location using roads:
Select the entity.
Choose Task Movement Move to Location (Plan Along Roads). The Move to Location (Plan Along Roads) dialog box opens.
Click on the terrain where you want the entity to move, or enter the coordinates of the location in the dialog box.
Click OK.
Movement Tasks for Entity-Level Scenarios — Move to Location (Plan Path)
The Move to Location (Plan Path) task is for surface and subsurface entities. It plots a route to the destination location based on the depth of water between the starting point and ending point. You specify the minimum depth required for the ship to maneuver. You can specify that the depth be based on the ship’s draft or you can enter a specific depth value. The ship’s draft is determined by calculating the distance its bounding box extends below its origin, as set in the Simulation Object Editor.
i The formula for calculating the draft is: draft = height/2 - offset (Up)
where height and offset are set in the Size group box in the Simulation Object Editor.
If you give this task to a submarine, VR-Forces assumes that it is moving on the surface.
For this task to work, your terrain must include S-57 data or depth information provided in a similar way.
To move a surface or subsurface vehicle to a location with path planning:
Select the entity.
Choose Task Movement Move to Location (Plan Path). The Move to Location (Plan Path) dialog box opens.
Click on the terrain where you want the entity to move, or enter the coordinates of the location in the dialog box.
Specify how you want VR-Forces to determine the minimum depth of water for the route.
If you want to see the path displayed, select Display Route.
Click OK.
Movement Tasks for Entity-Level Scenarios — Move to Waypoint
You can order a simulation object to move to a point or a simulation object. If naviga- tion data is present, simulation objects take it into account in planning their path to the waypoint.
Moving to a point is not the same as setting location. Setting location moves a simula- tion object instantaneously. Moving to a point causes a simulation object to travel through the terrain.
If you want a ground entity to use the road network to move to a waypoint, use the Move to Waypoint (Plan Along Roads) task. For details about road movement, please see “Entity Movement On Roads and Off Roads,” on page 26-22.
Rotary-wing entities are not able to reach moving waypoints or land on moving ships. A rotary-wing entity will approach a given waypoint or landing point, but will never completely reach the goal.
To send a simulation object to a waypoint or entity:
Select the simulation object.
Choose Task Movement Move to Waypoint, or click the Move to Waypoint button ( ) on the Tasks Toolbar. The Move to Waypoint dialog box opens.
Optionally, filter the selection list.
In the Name box, type the name of the waypoint or entity to move to, or select it in the list or on the terrain.
Click OK.
When you task an air platform entity to move to an object, be sure to take into account the altitude setting for the object and the terrain the entity has to pass over to complete the task.
Movement Tasks for Entity-Level Scenarios — Move to Waypoint (Plan Along Roads)
When an entity receives this task, it determines if there is a road network near by. If there is, it moves directly to the nearest point on the road network. Then it moves along the roads using road driving behavior until it gets to the point on the road that is closest to the destination. Then the entity moves off the road directly to the destination.
For more information about road driving and how the path planning tasks work, please see “Entity Movement On Roads and Off Roads,” on page 26-22.
To direct an entity to move to a waypoint using the road network:
Select the entity.
Choose Task Movement Move to Waypoint (Plan Along Roads). The Move to Waypoint (Plan Along Roads) dialog box opens.
Select the waypoint.
Click OK.
Movement Tasks for Entity-Level Scenarios — Move to Waypoint (Plan Path)
The Move to Waypoint (Plan Path) task applies to surface and subsurface entities. It plots a route to the waypoint based on the depth of water between the starting point and ending point. You specify the minimum depth required for the ship to maneuver. You can specify that the depth be based on the ship’s draft or you can enter a specific depth value. The ship’s draft is determined based by calculating the distance its bounding box extends below its origin, as set in the Simulation Object Editor.
i The formula for calculating the draft is: draft = height/2 - offset (Up)
where height and offset are set in the Size group box in the Simulation Object Editor.
If you give this task to a submarine, VR-Forces assumes that it is moving on the surface.
For this task to work, your terrain must include S-57 data or depth information provided in a similar way.
To move a surface or subsurface vehicle to a waypoint with path planning:
Select the entity.
Choose Task Movement Move to Waypoint (Plan Path). The Move to Waypoint (Plan Path) dialog box opens.
Select the waypoint to move to.
Specify how you want VR-Forces to determine the minimum depth of water for the route.
If you want to see the path displayed, select Display Route.
Click OK.
Movement Tasks for Entity-Level Scenarios — Patrol Route
To specify an orbit task:
Select the entity that you want to orbit.
Choose Task Movement Orbit. The Orbit dialog box opens.
Specify the coordinates of a point on the terrain around which the entity should orbit. You can click on the terrain to specify the points.
Specify the altitude at which to fly.
Specify the radius of the circle.
Select or clear the Clockwise option to specify the direction of travel.
Click OK.
When a simulation object patrols along a route, it moves to the nearest vertex of the route, to the end point, back to the beginning of the route, and then continues going back and forth along the route until given another command.
If a human is moving along a route outside of a navigation area and you move it away from the route or change the route, the entity plans a path to the route vertex it is moving to rather than moving to the nearest point on the route and then proceeding to the target vertex.
To order a simulation object to patrol a route:
Select the simulation object.
Choose Task Movement Patrol Route, or click the Patrol Route button ( ) on the Tasks Toolbar. The Patrol Along Route dialog box opens.
In the Name box, type the name of the route to patrol, or select the route in the list or on the terrain.
Click OK.
When you task an air platform entity to follow a route, be sure to take into account the altitude of the vertices and the terrain the entity has to pass over to complete the task.
Movement Tasks for Entity-Level Scenarios — Patrol Between
A simulation object can patrol between two point objects, simulation objects, or both. When a simulation object patrols between two objects, it goes to the starting object, then moves back and forth between the two objects.
To order a simulation object to patrol between two objects:
Select the entity.
Choose Task Movement Patrol Between, or click the Patrol Between button 
) on the Tasks Toolbar. The Patrol Between dialog box opens.
In the Name box for Point 1, type the name of the first object to patrol between, or select an object in the list or on the terrain.
In the Name box for Point 2, type the name of the second object to patrol between, or select an object in the list or on the terrain.
Click OK.
When you task an air platform entity to patrol between objects, be sure to take into account the altitude of the objects and the terrain the entity has to pass over to complete the task.
The Pattern Hold (Location) task causes a fixed-wing or rotary-wing entity to execute a standard hold pattern at the specified location.
To assign a pattern hold (location) task:
Select a fixed-wing or rotary-wing entity.
Choose Task Movement Pattern Hold (Location). The Pattern Hold (Location) dialog box opens.
Enter the location or select it on the terrain.
Specify the heading, speed, and altitude for the hold pattern.
Specify the turn direction for the hold pattern.
Click OK.
Movement Tasks for Entity-Level Scenarios — Rotary Wing Airlift Cargo to Location
The Pattern Hold (Waypoint) task causes a fixed-wing or rotary-wing entity to execute a standard hold pattern at the specified waypoint.
To assign a pattern hold (waypoint) task:
Select a fixed-wing or rotary-wing entity.
Choose Task Movement Pattern Hold (Waypoint). The Pattern Hold (Waypoint) dialog box opens.
Select the waypoint.
Specify the heading, speed, and altitude for the hold pattern.
Specify the turn direction for the hold pattern.
Click OK.
If the total weight of the objects plus the weight of the aircraft is greater than the aircraft can carry, the aircraft will embark the objects, but be unable to fly.
The unmanned aircraft needs to use the Quadcopter or Quadcopter Heavy Lift move- ment dynamics system.
To airlift cargo to a destination:
Select an unmanned aircraft.
Choose Task Movement Rotary Wing Airlift Cargo to Location. The Rotary Wing Airlift Cargo To Location dialog box opens.
Optionally, filter the list of object types.
Type the name of an object in the Name box, or in the Cargo Objects list, select one or more objects.
In the Cruise Altitude box, specify the altitude at which you want the aircraft to fly.
Specify the destination location by typing in the coordinates, or click the Destina- tion Location filter button 
) to give the Destination Location focus, and click on the terrain to specify the destination location.
Click OK.
Movement Tasks for Entity-Level Scenarios — Rotary Wing Land
The Rotary Wing Land task automates the process of landing a rotary-wing aircraft. Rotary-wing aircraft can land on points.
!
!
Although it is possible to land an entity on another entity, such as an aircraft carrier, if you want to embark an entity, you must use the Embark task, not a landing task.
To land a rotary-wing aircraft:
Select the entity.
Choose Task Movement Rotary Wing Land. The Rotary Wing Land dialog box opens.
In the Name box, type the name of the waypoint on which you want the entity to land, or select the waypoint in the list or on the terrain.
Click OK.
The Rotary Wing Retrieve Cargo task causes an unmanned aircraft to move to one or more cargo items and embark them onto itself. It hovers at the location of the last item retrieved until given further tasks.
The unmanned aircraft needs to use the Quadcopter or Quadcopter Heavy Lift move- ment dynamics system.
To cause a rotary-wing aircraft to retrieve cargo:
Select an unmanned aircraft.
Choose Task Movement Rotary Wing Retrieve Cargo. The Rotary Wing Airlift Cargo To Location dialog box opens.
Optionally, filter the list of object types.
Type the name of an object in the Name box or in the Cargo Objects list, select one or more objects.
In the Cruise Altitude box, specify the altitude at which you want the aircraft to fly.
Click OK.
Movement Tasks for Entity-Level Scenarios — Sail Heading
To unload cargo:
Select an unmanned aircraft.
Choose Task Movement Rotary Wing Unload Cargo. The aircraft unloads its cargo.
The Sail Heading task causes a surface entity to sail towards the specified heading. After turning to the heading, the entity moves at its ordered speed indefinitely.
To assign a sail heading task:
Select the entity.
Choose Task Movement Sail Heading. The Sail Heading dialog box opens.
Specify a heading in the indicated units (radians or degrees).
Specify the diameter of the turn.
Specify the direction of the turn, as follows:
Toward Heading. Chooses the most direct turn.
Port. Turns to port until it reaches the heading.
Starboard. Turns to starboard until it reaches the heading.
Click OK.
Movement Tasks for Entity-Level Scenarios — Turn to Heading
The Turn to Heading task provides a realistic way for ground vehicles to turn to a new heading. Rather than turning instantly, as happens with the Heading request, a vehicle pivots or makes a K-turn to the new heading. The turning behavior for an entity is controlled by its can-pivot parameter in the object parameter database.
To order an entity to turn to a heading:
Select the entity.
Choose Task Movement Turn to Heading. The Turn to Heading dialog box opens.
Type a heading.
In the Relative To list, select one of the following options:
North. Turn to the specified absolute heading.
Current Heading. Turn the specified number of degrees relative to the current heading.
Host (if embarked). If embarked, turn to the specified heading relative to the host simulation object.
Click OK.
28. Engagement Tasks for Entity-Level Scenarios
This chapter describes tasks in the engagement category that apply to entity-level scenarios.
Attack Aircraft with Guns 28-3
Drop Naval Depth Charge at Location 28-4
Drop Naval Mines Along Route 28-6
Execute Close Air Support 28-7
Launch Anti-Submarine Missile (Vertical) 28-12
Provide Suppressive Fire 28-17
Provide Suppressive Fire at Location 28-18
Engagement Tasks for Entity-Level Scenarios
Throw Grenade at Location 28-23
Engagement Tasks for Entity-Level Scenarios — Attack Aircraft with Guns
If a naval mine has been deployed, Arm Mine at Depth lets you change the mine’s parameters.
Arm Mine at Depth is a system scripted task. It is disabled by default.
To arm a mine:
Select the mine.
Choose Task Arm Mine at Depth. The Arm Mine at Depth dialog box opens.
Specify the depth at which to arm the mine.
Specify the radius within which target entities will detonate the mine.
Optionally, specify a time when the mine will be armed, in days and hours:minutes:seconds.
In the Targets list, add the types of entities that can trigger the mine, as follows:
Click the Add button ( ). The Entity Type dialog box opens.
Build an entity type by selecting options from the lists for each enumeration component or type an enumeration.
Click OK.
To specify that only hostile entities will set off the mine, select Hostile Only. If this setting is cleared, any entity will set off the mine.
Click OK.
To issue the Attack Aircraft with Guns task:
Select an aircraft entity that has a gun.
Choose Task Engagement Attack Aircraft with Guns. The Attack Aircraft with Guns dialog box opens.
Select the target entity.
Click OK.
Engagement Tasks for Entity-Level Scenarios — Drop Naval Depth Charge
The Drop Naval Depth Charge task drops a depth charge at the current location of the entity. To execute this task, an entity must have a Naval Depth Charge Deployment weapon system.
To drop a naval depth charge:
Select the entity.
Choose Task Engagement Drop Naval Depth Charge. The Drop Naval Depth Charge dialog box opens.
In the Naval Depth Charge list, select the type of depth charge to drop.
Specify the depth at which you want the depth charge to explode.
Click OK.
The Drop Naval Depth Charge at Location task causes an entity to move to the speci- fied location and drop a depth charge. To execute this task, an entity must have a Naval Depth Charge Deployment weapon system.
In this task, the location is the location of the entity when it drops the depth charge. Since the entity is flying, the location must include a reasonable altitude.
To drop a naval depth charge at a location:
Select the entity.
Choose Task Engagement Drop Naval Depth Charge at Location. The Drop Naval Depth Charge At Location dialog box opens.
In the Naval Depth Charge list, select the type of depth charge to drop.
Specify the depth at which you want the depth charge to explode.
Specify the location where you want to drop the depth charge.
By default, this task uses the altitude of the entity at the time the task is assigned as the altitude for the drop location. (Use Current Altitude check box.) If you specify an altitude and the check box is selected, VR-Forces ignores the altitude you entered and uses the current entity altitude. If you want to specify the altitude, clear the check box and make sure that you specify the altitude in the Altitude group box. If you click on the terrain to specify the X, Y location, the altitude gets set to 0, so be sure to enter the altitude you want after clicking on the terrain.
Click OK.
Engagement Tasks for Entity-Level Scenarios — Drop Naval Mine
The Drop Naval Mine task allows entities with a Naval Mine Deployment system to drop naval (underwater) mines at their current location.
To drop a naval mine:
Select the entity.
Choose Task Engagement Drop Naval Mine. The Drop Naval Mine dialog box opens.
In the Naval Mine list, select the type of mine to drop.
In the Mine Depth field, set the depth to drop the mine. Positive numbers are below sea level.
In the Arming Delay fields, set the time to elapse before the mine becomes armed. The first field is days. The second field is Hours:Minutes:Seconds.
In the Detonate Proximity field, set the distance from the mine within which a target entity will detonate the mine.
In the Trigger Entity Types list, add the types of entities that can trigger the mine, as follows:
Click the Add button ( ). The Entity Type dialog box opens.
Build an entity type by selecting options from the lists for each enumeration component or type an enumeration.
Click OK.
To specify that only hostile entities will set off the mine, select Hostile Only. If this setting is cleared, any entity will set off the mine.
Click OK.
Engagement Tasks for Entity-Level Scenarios — Drop Naval Mines Along Route
The Drop Naval Mines Along Route task allows entities with a Naval Mine Deploy- ment system to drop naval (underwater) mines while they travel along a route.
To drop naval mines along a route:
Select the entity.
Choose Task Engagement Drop Naval Mines Along Route. The Drop Naval Mines Along Route dialog box opens.
Select the route to follow.
In the Mine Spacing field, specify the distance between each mine.
In the Naval Mine list, select the type of mine to drop.
In the Mine Depth field, set the depth to drop the mine. Positive numbers are below sea level.
In the Arming Delay fields, set the time to elapse before the mine becomes armed. The first field is days. The second field is Hours:Minutes:Seconds.
In the Detonate Proximity field, set the distance from the mine within which a target entity will detonate the mine.
In the Trigger Entity Types list, add the types of entities that can trigger the mine, as follows:
Click the Add button ( ). The Entity Type dialog box opens.
Build an entity type by selecting options from the lists for each enumeration component or type an enumeration.
Click OK.
To specify that only hostile entities will set off the mines, select Hostile Only. If this setting is cleared, any entity will set off the mine.
Click OK.
Engagement Tasks for Entity-Level Scenarios — Execute Close Air Support
The Execute Close Air Support task assigns a fixed-wing fighter or bomber a close air support (CAS) task based on a 9-Line Briefing. You can call for a bombing run or a strafing run. The entity being tasked must be in the air to execute this task.
A 9-Line Briefing is a format used by U.S. armed forces to call in CAS. The Execute Close Air Support dialog box explicitly or implicitly requests all of the information in a 9-Line Briefing. However, the scripted task does not use all of this information to simulate CAS. (The procedure notes which fields are not used.) The task has parameters for all 9 lines to provide simulation authenticity. Since this is a scripted task, you could modify it to use all of the parameters.
To execute close air support:
Select the entity you want to execute close air support.
Choose Task Engagement Execute Close Air Support. The Execute Close Air Support dialog box opens (Figure 28-1).
In the Initial Point section, specify the location from which the aircraft should line up with the target by entering location values or clicking on the terrain.
In the Heading box, specify the approach heading. Optionally, specify an offset if you want the entity to favor a particular side of the line of approach.
In the Distance box, specify the distance from the initial point to the target. This information is not used by the task.
Select the target. Target selection satisfies lines 4, 5, and 6 of a 9-Line briefing, because it provides the location, altitude, and name of the target.
In the Mark Type box, specify how the target is marked. This information is not used by the task.
Engagement Tasks for Entity-Level Scenarios — Execute Close Air Support
If you are using a laser designator to mark the target, enter the laser code. (If you specify a laser code, an entity in the simulation must be lasing the target for the CAS to work.)
In the Friendlies box, specify the distance and direction of friendly forces from the target. This information is not used by the task.
In the Egress Heading box, specify the heading by which the attacking entity should leave after firing at the target. It will continue on this heading until it is given another task.
In the Attack Information section, select bomb or gun. If you select gun, the entity executes a strafing attack.
If you selected bomb, select a Bomb Choice and Bombing Altitude.
Click OK.
Engagement Tasks for Entity-Level Scenarios — Fire at Target
Explode Charge at Depth is a system scripted task. It is disabled by default.
To explode a depth charge:
Select the depth charge.
Choose Task Explode Charge at Depth. The Explode Charge at Depth dialog box opens.
Specify the depth.
Click OK.
When you issue this task, the entity ignores its rules of engagement and force types. Entities will fire at their own force if told to do so. The shooter must have line-of-sight to the target and have an appropriate weapon system and ammunition for the target.
To order an entity to fire at a target:
Select the entity you want to fire.
Choose Task Engagement Fire at Target, or click the Fire at Target button 
) on the Last Selected Object Panel or the Tasks Toolbar. The Fire at Target dialog box opens.
Select the target entity.
In the Weapon Selection group box, select an option as follows:
To let VR-Forces choose the weapon, select Automatic.
To choose the weapon yourself, select Manual and select a weapon from the list.
In the Maximum Rounds to Fire box, enter the number of rounds you want the entity to fire. (The entity stops firing when the target is destroyed or when the maximum number of rounds has been fired, whichever comes first.)
Engagement Tasks for Entity-Level Scenarios — Fire Cruise Missile
A cruise missile can fly directly to a target or follow a route.
To fire a cruise missile:
Choose Task Engagement Fire Cruise Missile. The Fire Cruise Missile dialog box opens (Figure 28-2).
Select the target from the list or on the terrain, or type its name in the Name box. Targets can be entities or points.
Select a route for the missile to follow or select the No Route check box. If no route is selected, the missile flies directly to the target.
Specify the ordered speed for the missile.
Specify the detonation proximity for the warhead. It will detonate within this range of the selected target.
Click OK.
Engagement Tasks for Entity-Level Scenarios — Fire for Effect Tasks
Fire-for-Effect on Entity.
Fire-for-Effect on Location, where location is a point on the terrain.
Fire-for-Effect on Target, where a target is a waypoint.
If an entity has more than one weapon, you can select multiple weapons to fire. However, they will all fire on the same target. You cannot target them independently.
To assign a Fire-for-Effect task:
Select the entity to which you want to assign the task.
Choose Task Engagement Fire-for-Effect on Entity (or Location or Target). The appropriate dialog box opens.
Identify the target as follows:
For FFE Entity, select the target entity in the list, select it on the terrain, or type its name in the Name box.
For FFE Location, click a location on the terrain, or enter the coordinates.
For FFE Target, select a point from the list, or select it on the terrain.
4.
i For FFE Entity and FFE Target, you can filter the target list.
In the Select Weapons list, select the weapons that you want to fire.
Specify the number of rounds.
Optionally, specify the height above the terrain at which rounds should detonate.
Click OK.
The Fire-for-Effect tasks are only meaningful when assigned to artillery entities or surface vessels that have naval guns.
When you choose Fire-for-Effect on Entity, if the target entity is moving, VR-Forces dead reckons its position and the artillery fires at its expected location, not the location it was at the start of the task.
Artillery entities have maximum and minimum ranges. To see these ranges, enable range rings for the entity. (For details, please see “Displaying Threat and Sensor Range Rings,” on page 18-24.) The back- end console window prints messages when you select targets that are outside of the entity’s range.
Engagement Tasks for Entity-Level Scenarios — Lase Target
Ordinarily, naval guns fire their munitions in a parabola, similar to artillery. However, they can also fire directly at a target if the following conditions are true:
The target’s range is greater than the weapon’s minimum range, but less than the first value in its range list.
The capable-of-direct-alignment parameter for the weapon system’s naval-gun- controller is set to True.
The firing entity has line-of-sight to the target.
The Lase Target task simulates aiming a laser beam at a target to guide a laser guided weapon. By default, entities with laser capability lase autonomously. Use this task if you want to lase a specific target. An entity can lase a target while it is executing a move- ment task.
To lase a target, an entity must have a Laser Designator system.
To lase a target:
Select the entity that will aim the laser.
Choose Task Engagement Lase Target. The Lase Target dialog box opens.
Select the entity that you want to lase.
Click OK.
To launch an anti-submarine missile:
Select the surface entity.
Choose Task Engagement Launch Anti-Submarine Missile (Vertical). The Launch Anti-Submarine Missile (Vertical) dialog box opens.
Select the target entity.
Specify the location at which to drop the homing torpedo.
Click OK.
Engagement Tasks for Entity-Level Scenarios — Launch Smoke
Fixed-wing and rotary-wing entities can launch counter measures, such as chaff and flares. Launch Counter Measures is not an exclusive task. It does not interrupt an entity’s current task. (For more information, please see “Launching Counter Measures (Chaff and Flare),” on page 9-19.)
To launch counter measures:
Select the entity that you want to launch counter measures.
Choose Task Engagement Launch Counter Measures. The Launch Counter Measures dialog box opens.
In the Counter Measure Types list, select the type of counter measures you want to launch.
In the Number To Fire box, specify the number of counter measures to launch.
In the Time Between Fires box, specify the amount of time, in seconds, between each counter measure launch.
Click OK.
The Launch Smoke task causes an entity to create a smoke cloud. The cloud is created as an environmental object. It grows over time.
An entity can launch a smoke cloud towards a threat or in a specific direction. Smoke clouds affect sensors. They do not affect entity movement.
Tactical smoke is delivered by the M250 smoke grenade launcher. An entity must have this system to execute this task.
To launch a smoke cloud:
Select the entity that you want to launch smoke.
Choose Task Engagement Launch Smoke. The Launch Smoke dialog box opens.
Select At Nearest Threat or Toward Compass Heading.
If you selected Toward Compass Heading, specify a compass heading, in degrees.
Click OK.
Engagement Tasks for Entity-Level Scenarios — Launch Torpedo
Torpedoes rise to target depth at a fixed rate. If a submarine is quite close to a target when it fires, the torpedo might not be able to rise to target depth in the distance from the submarine to the target. If this happens, it circles until it reaches target depth.
To launch a torpedo that moves at a fixed depth:
Select a subsurface entity.
Choose Task Engagement Launch Torpedo Anti-ship (Fixed Depth). The Anti-ship (Fixed Depth) dialog box opens.
Optionally, filter the entity list.
Select the target entity.
In the Homing Start Delay box, enter the amount of time that the torpedo should travel on its initial bearing.
In the Cruise Depth box, specify the depth the torpedo should travel at. It will remain at this depth.
In the Initial Bearing box, specify the bearing the torpedo should travel at until it begins homing in on the target.
In the Proximity Trigger Distance box, set the distance from a target at which the torpedo will detonate.
Click OK.
Engagement Tasks for Entity-Level Scenarios — Launch Torpedo
The anti-submarine torpedo homes in on the center of the target.
To launch an anti-submarine torpedo:
Select a subsurface entity.
Choose Task Engagement Launch Torpedo Anti-submarine. The Anti- Submarine dialog box opens.
Optionally, filter the entity list.
Select the target entity.
In the Homing Start Delay box, enter the amount of time that the torpedo should travel on its initial bearing.
In the Initial Bearing box, specify the bearing the torpedo should travel at until it begins homing in on the target.
In the Proximity Trigger Distance box, set the distance from the target at which the torpedo will detonate.
Click OK.
Engagement Tasks for Entity-Level Scenarios — Place IED
The Place IED task lets a human entity place an improvised explosive device (IED) at a particular location and move to a post-placement location. This task also sets the parameters for how the IED will be armed.
To assign a place IED task to a human entity:
Select the entity.
Choose Task Engagement Place IED. The Place IED dialog box opens (Figure 28-3).
Enter the location where the IED should be placed, or click on the terrain to specify the location.
In the Placement Duration box, enter the amount of time it takes to place the IED.
Select a fuse type from the Fuse Type list.
For a timed delay fuse, specify the time to delay in the Time Delay box.
For a proximity fuse, specify the distance from the IED within which another entity will trigger the IED.
Enter the location where the entity should move to after it places the IED, or click on the terrain to specify the location.
Engagement Tasks for Entity-Level Scenarios — Provide Suppressive Fire
In the Arming Location list select Arm at Placement Location to arm the IED as soon as it is placed, or Arm at Post Placement Location to arm it when the entity reaches the post-placement location.
Click OK.
The Provide Suppressive Fire task tells an entity to fire at a point, along a line, or in an area, one meter above the terrain. For more information, please see “Suppressive Fire Tasks,” on page 26-32.
i The target of suppressive fire must be at least 25 meters away.
To order suppressive fire on a point, a line, or in an area:
Select the entity that will deliver suppressive fire.
Choose Task Engagement Provide Suppressive Fire. The Provide Suppressive Fire dialog box opens.
Select the tactical graphic to fire at.
In the Duration of Rapid Fire box, type the number of seconds for the rapid fire.
In the Total Fire Time box, type the number of minutes the entity should provide suppressive fire.
In the Maximum Round to Fire box, type the maximum number of rounds to fire.
In the Gun list, select the gun to use.
Click OK.
Engagement Tasks for Entity-Level Scenarios — Provide Suppressive Fire at Location
The Provide Suppressive Fire on Location task tells an entity to fire at a location, one meter above the location. For more information, please see “Suppressive Fire Tasks,” on page 26-32.
i The target of suppressive fire must be at least 25 meters away.
To order suppressive fire on a location:
Select the entity that will deliver suppressive fire.
Choose Task Engagement Provide Suppressive Fire at Location. The Provide Suppressive Fire at Location dialog box opens.
Specify the location.
In the Duration of Rapid Fire box, type the number of seconds for the initial burst of rapid fire.
In the Total Fire Time box, type the number of minutes the entity should provide suppressive fire.
In the Maximum Round to Fire box, type the maximum number of rounds to fire.
In the Gun list, select the gun to use.
Click OK.
Fixed-wing entities can release bombs targeted to a laser spot, a location, or an entity. The Release Bomb on Laser Spot task requires that another entity lase the target. You must synchronize the laser code for the bomber with the laser code for the lasing entity. Use of lasers is described in:
“Lase Target,” on page 28-12.
“Synchronize Laser Code,” on page 34-43.
Engagement Tasks for Entity-Level Scenarios — Release Bomb Tasks
The Release Bomb on Target and Release Bomb on Location tasks cause a bomb to be immediately dropped. The task assumes that the target is in front of the aircraft. The targetable area is a circle whose radius is defined by the altitude of the airplane and its maximum range.
The bomb navigates toward its target based on max-range and max-range-altitude parame- ters (configurable in the Simulation Object Editor). A bomb can navigate max-range meters laterally if it is at max-range-altitude meters above the target. As the altitude changes, the distance it can travel changes accordingly, so at half of max-range-altitude it can travel half of max-range.
The bomb follows a straight line path from its launch to the point it is navigating to, assuming it can reach it. If its target point is out of range, it gets as close to the target as it can. If the target point moves, the bomb changes course and heads for the new target point.
Use of a Release Bomb task requires that you determine if the airplane is in range of the target. The Execute Close Air Support task ensures that the airplane is within range of the target before it drops its bomb. Therefore, we recommend using that task rather than one of the Release Bomb tasks.
The Release Bomb on Laser Spot task steers the bomb towards the laser point.
To assign a release bomb task:
Select the entity that will release the bomb.
Choose Task Engagement task, where task is Release Bomb on Laser Spot, Release Bomb on Location, or Release Bomb on Target. The appropriate dialog box opens.
In the Bomb Types list, select the type of bomb you want to drop.
In the Detonation Proximity box, enter the distance from the target at which the bomb should detonate.
For Release Bomb on Location, specify the location. For Release Bomb on Target, select the target.
Click OK.
Engagement Tasks for Entity-Level Scenarios — Sector Search Operation
The Sector Search Operation task tasks an embedded entity to fly a sector search and rescue pattern. In addition to the basic search and rescue parameters, you have the following options:
If there are no undeployed embedded entities available, divert an already deployed entity to do the search.
Force the parent entity to wait until the search is complete and the embedded entity is recovered until it continues with its plan or allow the parent entity to continue with its plan while the search is underway.
To execute a sector search operation:
Choose an entity that has embedded entities.
Choose Task Sector Search Operation. The Sector Search Operation dialog box opens.
Select the Allow Diversion check box if you want a deployed entity to be diverted to this task if necessary.
Select the Recover When Finished check box if you want the parent entity to wait until it recovers the deployed entity before it continues with its plan.
Specify the starting point of the search.
In the Leg box, specify the length of each leg of the search.
In the Altitude box, specify the altitude the search aircraft should fly at.
In the Air Speed box, specify the speed of the search aircraft.
Click OK.
Engagement Tasks for Entity-Level Scenarios — Strafe Ground Target
Fixed-wing entities that have the appropriate armament can strafe ground targets. The Strafe Ground Target task takes the following parameters:
Target Point. The target point to strafe.
Initial Point. The point at which the aircraft reaches strafing altitude and lines up to strafe the target point. VR-Forces enforces a minimum distance from the initial point to the target. It varies based on the plane’s dive angle, strafe range, entry speed, and other parameters. Two kilometers is a good minimum for most entities. If the initial point is too close to the target, VR-Forces sends an error message to the entity console.
Target Types. The type of entity or object to be targeted at the target point. If you specify none, the entity strafes the target location. If you specify an object type, the entity looks for that object type. If it finds the target type, it strafes it. If it does not find the target type, it either strafes the target point (default behavior) or aborts the strafing run, depending on the state of the Abort Without Target check box.
Egress Maneuver and Egress Heading. The way the aircraft should exit the strafing run and the heading at which it exits.
You can also initiate a strafing run from the Execute Close Air Support task. Table 28-1 shows how arguments to the Execute Close Air Support task map to the Strafe Ground Target task.
Table 28-1: CAS to Strafe argument mapping
CAS Argument Strafe Ground Target Argument
CAS Argument Strafe Ground Target Argument
Initial Point Initial Point.
Target Point Target Point.
Target: a waypoint Target: an entity
Offset: none Offset: left Offset: right
Target Type: None (target location). Target Type: Target the indicated entity.
Egress Maneuver: Immediate Climb. Egress Maneuver: Juke Left.
Egress Maneuver: Juke Right. Abort without target.
Egress Heading Final Egress Heading.
Engagement Tasks for Entity-Level Scenarios — Strafe Ground Target
To strafe a ground target:
Select the entity that will make the strafing run.
Choose Task Engagement Strafe Ground Target. The Strafe Ground Target dialog box opens (Figure 28-4).
Click the terrain to specify the initial point or type the coordinates.
Select the target point.
Optionally, select a target type.
If you select a target type other than none, select the Abort Without Target check box to abort the strafing run if the target type is not found. Clear the check box if you want the entity to strafe the target point if the target type is not found.
Select an egress maneuver.
Optionally, specify an egress heading.
Click OK.
Engagement Tasks for Entity-Level Scenarios — Throw Grenade Tasks
To assign the Sweep Naval Mines task:
Select the entity.
Choose Task Movement Sweep Naval Mines. The Sweep Naval Mines dialog box opens.
Select the route to follow.
Specify the sensing range. The default is 300 meters.
Optionally, specify the disarm failure probability. This is the percentage chance that a mine will be found, but not disabled.
Click OK.
Infantry characters can throw hand grenades at a target or at a location. An entity can throw the following types of grenades:
M67 - fragmentation.
M84 - stun, or flashbang.
M18 - colored smoke.
M83 - white smoke.
To throw a hand grenade to a location:
Select the entity.
Choose Task Engagement Throw Grenade at Location. The Throw Grenade at Location dialog box opens.
In the Grenade Type list, select the type of grenade to throw.
Specify the location.
Click OK.
Engagement Tasks for Entity-Level Scenarios — Throw Grenade Tasks
To throw a hand grenade at a target:
Select the entity.
Choose Task Engagement Throw Grenade at Target. The Throw Grenade at Target dialog box opens.
Specify the target.
In the Grenade Type list, select the type of grenade to throw.
Click OK.
This chapter describes the tasks for humans and crowds that apply to entity-level scenarios. Movement and engagement tasks that apply to humans are described in Chapter 27, Movement Tasks for Entity-Level Scenarios and Chapter 28, Engagement Tasks for Entity-Level Scenarios.
Human and Crowd Tasks — Civilian Idle
To assign a civilian idle task:
Select the human characters.
Choose Task Movement Civilian Idle.
If a human is within approximately one meter of an open door, this task causes the door to close. This task applies to doors controlled by switch nodes in the terrain, not articu- lated parts.
To close a door:
Move a human to within one meter of an open door.
Choose Task Terrain Close Door.
If a human is within approximately one meter of an open window, this task causes the window to close. This task applies to windows controlled by switch nodes in the terrain, not articulated parts.
To close a window:
Move a human to within one meter of an open window.
Choose Task Terrain Close Window.
Human and Crowd Tasks — Crowd Along Line
The Create Pedestrians task adds pedestrians to a crowd. If the crowd is part of a pedes- trian area, the new pedestrians wander within the area. If the crowd is not part of a pedestrian area, their wandering is unrestricted.
When the Create Pedestrians task runs, it gives each new pedestrian a Move To Location task, followed by a Wander task. The Create Pedestrians task is not complete until all the Wander tasks have been sent. Therefore, the task does not complete as quickly as you might expect simply based on when the pedestrians get created.
To add pedestrians to a crowd:
Select the crowd or select a pedestrian area.
Choose Task Create Pedestrians.
Select a placement option.
Click OK.
The Crowd Along Line task causes a crowd to gather to the left or right of a line at its center point.
To cause a crowd to gather along a line:
Select the crowd.
Choose Task Movement Crowd Along Line. The Crowd Along Line dialog box opens.
Select the line the crowd should crowd along.
Specify left or right of the line.
Click OK.
Human and Crowd Tasks — Crowd Around Location
The Crowd Around Location task causes a crowd unit to cluster around the specified location.
To cause a crowd to crowd around a location:
Select the crowd.
Choose Task Movement Crowd Around Location. The Crowd Around Loca- tion dialog box opens.
Click on the terrain to specify the location or enter the coordinates in the dialog box.
Click OK.
The Crowd Around Object task calculates target locations for the members of the crowd to move to that are greater than or equal to the minimum distance specified from the object. However, due to interactions between the crowd members as they move, it is possible that some will end up closer to the target object than the minimum distance.
To cause a crowd to crowd around a simulation object:
Select the crowd.
Choose Task Movement Crowd Around Object. The Crowd Around Object dialog box opens.
In the Filter list, select All Entities or Points.
Select the simulation object or point you want the crowd to gather around.
In the Minimum Distance box, specify the minimum distance between a member of the crowd and the object.
Click OK.
Human and Crowd Tasks — Disperse Crowd
The Crowd in Front of Entity task causes a crowd to gather in front of an entity, where the front of the entity is determined based on its heading.
To cause a crowd to crowd in front of an entity:
Select the crowd.
Choose Task Movement Crowd in Front of Entity. The Crowd in Front of Entity dialog box opens.
Select the entity you want the crowd to gather in front of.
Click OK.
VR-Forces can specify the movements and appearance of DI-Guy models used in the Stealth observer mode and in 3D visualization programs such as VR-Vantage Stealth. The DI-Guy Animation task directs the 3D model to engage in a one-time or repeated series of motions. VR-Forces does not simulate the actions that the 3D model performs; it just adjusts the location and orientation of the VR-Forces entity to synchronize it with the 3D model’s animated behavior. To change a 3D model’s appearance, use the DI-Guy Appearance set data request. For details, please see “DI-Guy Characteristics (Appearance, Head, Body Weight),” on page 34-16.
i The DI-Guy Animation task applies only to lifeform entities.
To specify a DI-Guy animation:
Select the lifeform entity whose behavior you want to animate.
Choose Task DI-Guy DI-Guy Animation. The DI-Guy Animation dialog box opens.
In the Animation list, select an animation.
In the Animate group box, specify the duration of the animation.
Click OK.
The Disperse Crowd task causes a crowd to wander freely.
To disperse a crowd:
Select the crowd.
Choose Task Movement Disperse Crowd.
Human and Crowd Tasks — Flee from Entities
The Flee from Entities task causes a human entity to flee from a specified entity. It flees until it is a specified distance away. This task can be assigned to individual humans and to crowds. The entities must be within a navigation area.
To assign a Flee from Entities task:
Select the entity.
Choose Task Movement Flee From Entities. The Flee From Entities dialog box opens.
Select the entity that you want this entity to flee from.
Optionally, specify the radius of the flight zone.
Click OK.
To open a door:
Move a human to within one meter of a closed door.
Choose Task Terrain Open Door.
If a human is within approximately one meter of a closed window, this task causes the window to open. This task applies to windows controlled by switch nodes in the terrain, not articulated parts.
To open a window
Move a human to within one meter of a closed window.
Choose Task Terrain Open Window.
Human and Crowd Tasks — Wander
To cause a crowd to protest around a location:
Select the crowd.
Choose Task Movement Protest. The Protest Around Location dialog box opens.
Specify a location.
Click OK.
The Protest Along Line task causes a crowd to gather along a specified line and contin- uously execute a series of protest animations.
To cause a crowd to protest along a line:
Select the crowd.
Choose Task Movement Protest Along Line. The Protest Along Line dialog box opens.
Specify a line.
Specify which side of the line to protest on.
Click OK.
The Wander task causes a lifeform entity to move to a series of randomly chosen loca- tions for the specified amount of time. You can constrain wandering to a specified area. If the entity is using a preferred navigation mode and there is preferred road data for the terrain, the Wander task will only choose destinations that meet the preference criteria. The entity must be in a navigation area.
To assign a Wander task:
Select the entity.
Choose Task Movement Wander. The Wander dialog box opens.
Select a Duration option – Indefinitely or Timed. If you select Timed, specify the amount of time to wander in days, hours, minutes, and seconds.
Select a Movement options – Free or Restricted To Area. If you select Restricted To Area, type the name of an area or select it in the list or on the map.
Click OK.
Human and Crowd Tasks — Wander In Area
To assign a crowd to wander:
Select the crowd.
Choose Task Movement Wander In Area. The Wander In Area dialog box opens.
Select the area to wander in.
Click OK.
30. Embarkation, Wait, Radio, and Other Tasks
This chapter describes the tasks supplied with VR-Forces that are categorized as Embar- kation, Radio, Wait, Other, and uncategorized.
Tasks for Moving Articulated Parts 30-11
Deploying Embedded Entities 30-14
Recovering Deployed Entities 30-14
Deploying an Entity with a Task 30-16
Embarkation, Wait, Radio, and Other Tasks
Deploy Sonobuoys Along Route 30-17
This section describes tasks for simulating embarking and disembarking. Simulation objects move to the parent simulation object to embark, and move away after disem- barking. For immediate embarkation and disembarkation, use the Embarked and Disembarked set data requests or the embarkation commands on the Objects menu. For a conceptual discussion of embarkation, please see “Embarking and Disembarking Simulation Objects,” on page 19-7.
The Disembark task causes a simulation object to move to the parent simulation object’s egress (exit) point and disembark. If the selected simulation object is a unit (disaggregated), the disembark task is given to all embarked subordinates. The task is considered complete when all subordinates are disembarked. To disembark simulation objects immediately, that is, without using a task, please see “Embarking and Disem- barking Simulation Objects,” on page 19-7.
When a simulation object disembarks, it simply goes to the disembarka- tion location. If you plan to disembark several simulation objects from the same parent by giving them disembark tasks, you are responsible for making sure that each simulation object moves from the disembarkation point before the next simulation object disembarks.
Units in the aggregated state cannot embark or disembark. If a disaggre- gated unit is embarked, you cannot aggregate it either manually, or as a result of automated aggregation conditions.
To disembark a simulation object:
Select the simulation object you want to disembark.
Choose Task Embarkation Disembark, or click the Disembark button ( ) on the Last Selected Object Panel or the Tasks Toolbar.
The Disembark All task is given to a parent simulation object. It gives a Disembark task to all embarked simulation objects except aggregates. When you issue a Disembark All task, VR-Forces tries to disembark the simulation objects sequentially and have them move to sufficiently dispersed locations to avoid collision problems.
To disembark all simulation objects from a parent simulation object:
Select the parent simulation object.
Choose Task Embarkation Disembark All.
i Units in the aggregated state cannot embark or disembark.
The Embark task is valid only if the specified parent simulation object is configured to accept the simulation object that wants to embark on it. If you task a simulation object to embark on a simulation object that is not configured to receive it, for example, you task a DI to embark on an M1A2, the simulation object will not respond to the task. If you want to embark a simulation object on a simulation object that is not configured to receive it, you can use the immediate embarkation process. For details, please see “Embarking and Disembarking Simulation Objects,” on page 19-7.
Table 30-1 lists the simulation entities that support embarkation that have slots config- ured and the number and type of embarked entities they can hold. (Other simulation objects may support embarkation, but not have slots configured. Slots for humans represent passengers only, not crew members.) High fidelity entities (HF column) have polygonal models of the entity and embarkation slots defined in such a way that the embarking entities can smoothly embark on the host entity when viewed in the 3D view or VR-Vantage.
Table 30-1: Embarkation support
Entity Can Carry HF
Entity Can Carry HF
AH-6 Little Bird 1 human
Aircraft Carrier 12 fighters or 9 fighters and 2 cargo x planes. Three helicopters. 70 planes below deck.
Arleigh Burke-class Destroyer 1 aircraft
Bell 206 Jet Ranger 4 humans
Bell 406 6 humans
BMP-2 AFV 7 humans
BTR-80 Armored\ Personnel Carrier 7 humans
C-5 Galaxy 73 humans or 3 ground vehicles
C-130 Hercules 92 humans or 3 ground vehicles
C-17 Globemaster 134 humans or 3 ground vehicles
CH-46E Sea Knight 11 humans
CH-47 Chinook 55 humans
Table 30-1: Embarkation support
Entity | Can Carry | HF |
CH-53E Super Stallion | 55 humans | |
EC 145 | 9 humans | |
Fire Engine | 6 humans | |
GAZ-69 Utility Vehicle | 4 humans | |
Guided Missile Destroyer | 2 helicopters | |
CH-47 Chinook | 55 humans | |
HMMWV (all types) | 4 humans | x |
LCAC | 9 HMMWVs or 4 trucks or 1 M1A2 or 1 generic ground vehicle | |
LSD-49 Harpers Ferry | 2 LCACs and 2 helicopters | x |
M-939A2 5-Ton Truck | 14 humans | x |
M1126 Stryker ICV | 9 humans | |
M113 Armored Utility Vehicle | 11 humans | |
M2A2 Bradley IFV | 6 humans | |
M939A2 5-Ton Truck | 14 humans | |
MD500 | 4 humans | |
MH-47 Chinook | 55 humans | |
MH-6 Little Bird | 1 human | |
MH-60 Blackhawk | 11 humans | |
MH-60L Blackhawk DAP | 11 humans | |
Mi-2 Hoplite | 8 humans | |
MT-LB Multipurpose Armored Vehicle | 11 humans | |
Nimitz Class Carrier | 48 aircraft, including fighter jets, helicopters, and reconnaissance. | |
OH-58 Kiowa | 1 human | |
P-3 Orion | 11 humans | |
Rigid Hull Inflatable Boat | 8 humans | |
Rigid Hull Inflatable Boat - Civilian | 6 humans | |
SH-60 Seahawk | 11 humans | |
Space Shuttle | 7 humans | |
Technical Truck | 4 humans | |
Tractor Trailer Cab | 2 humans | |
Tractor Trailer with Cab | 2 humans | |
UH-60 Blackhawk | 11 humans |
Table 30-1: Embarkation support
Entity Can Carry HF
Entity Can Carry HF
UH-72 Lakota 9 humans
Osprey 24 humans, 1 light ground vehicle
VAB APC 10 humans
The aircraft carrier can carry both fixed-wing and rotary-wing aircraft. After the deck positions are used, additional entities embarked are stored below deck, as in a low- fidelity model.
!
!
If you are using HLA and want to use the embarkation feature, you must use RPR FOM 2, draft 17 or later.
If the embarkation spaces on the parent simulation object are full, VR- Forces sends a message to the back-end console and the simulation object does not try to embark.
If you give multiple simulation objects embark tasks for the same parent, you are responsible for spreading the tasks over time so that the simula- tion objects do not all converge on the parent at the same time, which would result in problems due to collision avoidance.
A simulation object is considered embarked as soon as it reaches its ingress point. In plan view mode, its icon is hidden immediately. However, in a 3D mode, the simulation object may need to continue moving to reach its slot on the parent. If you task the parent simulation object to move before a simulation object has moved to its slot, the embarking 3D model may end up in an odd position relative to the parent simulation object. To avoid this visual problem, allow time for the embarking simulation object to stop moving before the parent entity moves.
To embark a simulation object:
Select the simulation object .
Choose Task Embarkation Embark, or click the Embark button ( ) on the Last Selected Object Panel or the Tasks Toolbar. The Embark On dialog box opens.
Unlike the Embark On dialog box that opens when you choose Objects Embark, the Embark On dialog box for the Embark task does not allow you to choose the embarkation point.
Select the parent simulation object (the simulation object to embark on) or type its name in the Name box.
If the parent simulation object has slots of a specific type and you want the simula- tion object to embark in a slot of a particular type, select the type in the Slot Type list. Slots of that type are now listed in the Slot Name list. (For information about slot types and slot names, please see “Configuring Embarkation,” on page 65-34 and “Configuring Slots,” on page 65-38.)
Select a slot from the Slot Name list.
If you want the simulation object to use any available slot, select the Choose Any Slot if Requested Slot Not Available check box.
Click OK.
This section describes the tasks that let you use the VR-Forces radio network to send messages, tasks, and set data requests.
The Send Radio Set task lets you send a set data request to a simulation object using a VR-Forces radio message. The receiving entity executes the set data request as if you had issued it directly to the entity from the Set menu or a set data request in a plan.
Since VR-Forces has no idea what type of entity you might want to give a set data request to, when you add this task the full list of possible sets is available. There is no context sensitivity like there is when you select a simulation object and view the Set menu. It is up to you to be sure that the set you are assigning to a simulation object is supported by that object type.
Embarkation, Wait, Radio, and Other Tasks — Radio Tasks
To send a set data request radio message:
Select the simulation object that will send the message.
Choose Task Radio Send Radio Set. The Send Radio Set dialog box opens.
To send the message to all simulation objects configured to receive messages from this simulation object’s radio, select the Broadcast check box. (For details about configuring the radio model, please see “Configuring Radios,” on page 74-4.)
To send the message to a specific simulation object, in the Send Set To group box, in the Name text box, type the name of the simulation object that will receive the set data request message, or select the simulation object in the list or on the terrain.
A list of set data requests is displayed (Figure 30-1).
Select the set data request you want to send.
Click OK. If the set data request requires input, an appropriate dialog box opens. If no input is required, the task setup is finished.
If a dialog box opens, complete the dialog box as described in Chapter 34, Setting the State of Simulation Objects.
Click OK.
The Send Radio Task task lets you send a task to a simulation object using a VR-Forces radio message. The receiving simulation object executes the task as an independent task.
Since VR-Forces has no idea what type of simulation object you might want to give a task to, when you add this task the full list of possible tasks is available. There is no context sensitivity like there is when you select a simulation object and view the Task menu. It is up to you to be sure that the task you are assigning to a simulation object is supported by that object type.
To send a task radio message:
Select the simulation object that will send the message.
Choose Task Radio Send Radio Task. The Send Radio Task dialog box opens.
To send the message to all simulation objects configured to receive messages from this simulation object’s radio, select the Broadcast check box. (For details about configuring the radio model, please see “Configuring Radios,” on page 74-4.)
To send the message to a specific simulation object, in the Send Task To group box, in the Name text box, type the name of the simulation object that will receive the task message, or select the simulation object in the list or on the terrain.
A list of tasks is displayed (similar to Figure 30-1).
Select the task you want to send.
Click OK. If the task requires input, an appropriate dialog box opens. If no input is required, the task setup is finished.
If a dialog box opens, complete the dialog box as described in Chapter 34, Setting the State of Simulation Objects.
Click OK.
Embarkation, Wait, Radio, and Other Tasks — Wait Tasks
The Send Text Message task lets you send a text message to a simulation object using a VR-Forces simulated radio message. The receiving simulation object must be on the same network as the sending simulation object. Usually this means the same unit or same force. The receiving simulation object can test for receipt of the message in a conditional statement in its plan. (For details, please see “Receive Text Message,” on page 35-13.)
To send a text message:
Select the simulation object that will send the message.
Choose Task Radio Send Text Message. The Send Text dialog box opens.
To send the message to all simulation objects configured to receive messages from this simulation object’s radio, select the Broadcast check box. (For details about configuring the radio model, please see “Configuring Radios,” on page 74-4.)
To send the message to a specific simulation object, in the Name text box, type the name of the simulation object that will receive the task message, or select the simu- lation object in the list or on the terrain.
In the Message Text box, type the message.
Click OK.
The Wait task is not equivalent to an immediate stop task. If a simulation object is moving and you give it a Wait task, it might not stop immediately, particularly if a controller such as the collision avoidance controller is controlling its movement.
To order a simulation object to wait indefinitely:
Select the simulation object.
Choose Task Wait Wait.
If you put an indefinite wait in a plan, the simulation object does not progress through its plan until it receives another command.
To order a simulation object to wait a specific amount of time:
Select the simulation object.
Choose Task Wait Wait Duration. The Wait Duration dialog box opens.
Specify the duration of the wait in hours, minutes, and seconds.
Click OK.
To order a simulation object to wait until a specific elapsed simulation time:
Select the simulation object.
Choose Task Wait Wait Elapsed. The Wait Elapsed dialog box opens.
Specify the elapsed time from the start of the simulation, in hours, minutes, and seconds.
Click OK.
For information about simulation time and simulated exercise time, please see “Simula- tion Time,” on page 3-10.
Some entity models have articulated parts, such as doors and periscopes, that you can move.
The Close Cargo Door task closes a cargo door on an entity that has a cargo door artic- ulated part.
To close a cargo door:
Select the entity.
Choose Task Cargo Door Close Cargo Door.
Embarkation, Wait, Radio, and Other Tasks — Tasks for Moving Articulated Parts
The Deploy Refueling Boom task causes an aircraft that has a refueling boom articu- lated part to extend it (Figure 30-2). Use Stow Refueling Boom (“Stow Refueling Boom,” on page 30-13) to retract the boom.
Figure 30-2. KC-135 Stratotanker with refueling boom deployed
To deploy a refueling boom:
Select the entity.
Choose Task Refueling Boom Deploy Refueling Boom. The boom is extended.
The Lower Periscope task lowers the periscope of a subsurface entity. The periscope is an articulated part that is visible in the Stealth view.
To lower a submarine’s periscope:
Select the entity.
Choose Task Other Lower Periscope.
The Open Cargo Door task opens a cargo door on an entity that has a cargo door artic- ulated part.
Figure 30-3. CH-53E Super Stallion with open cargo door
To open a cargo door:
Select the entity.
Choose Task Cargo Door Open Cargo Door.
The Raise Periscope task raises the periscope of a subsurface entity. The periscope is an articulated part that is visible in the Stealth observer mode.
To raise a submarine’s periscope:
Select the entity.
Choose Task Other Raise Periscope.
The Stow Refueling Boom task causes an aircraft that has a refueling boom articulated part to stow it. Use Deploy Refueling Boom (“Deploy Refueling Boom,” on
page 30-12) to deploy a refueling boom.
To stow a refueling boom:
Select the entity.
Choose Task Refueling Boom Stow Refueling Boom. The boom contracts.
You can deploy and recover embedded entities. You can also task an embedded entity to conduct a sector search. For details about embedded entities, please see “Embedded Entities,” on page 19-12.
To add an embedded entity to a simulation, you deploy it from the parent entity.
You can deploy an embedded entity explicitly or implicitly (by assigning a task to it). An embedded entity’s label displays its name and the name of its parent.
There is a delay of a few seconds from the time a deployment is ordered and the time it is executed.
To deploy an embedded entity explicitly:
Select the parent entity.
Choose Task Embedded Entity Deploy. The Deploy dialog box opens.
Select the entity you want to deploy.
Click OK. The embedded entity gets deployed next to the parent entity in the rela- tive position in its configuration.
If you want an embedded entity that has been deployed to return to its parent, you can have the parent recover it. If you do not recover it, the deployed entity continues to function in the scenario just like any other entity.
To recover a deployed embedded entity:
Select the parent entity.
Choose Task Embedded Entity Recover. The Recover Embedded Entity dialog box opens.
Select the entity you want to recover.
Click OK. The parent sends a message to the deployed entity to return. It returns and is embedded again.
Embarkation, Wait, Radio, and Other Tasks — Embedded Entity Tasks
The Sector Search Operation task causes an embedded entity to fly a sector search and rescue pattern. In addition to the basic search and rescue parameters, you have the following options:
If there are no undeployed embedded entities available, divert an already deployed entity to do the search.
Force the parent entity to wait until the search is complete and the embedded entity is recovered until it continues with its plan or allow the parent entity to continue with its plan while the search is underway.
To execute a sector search operation:
Choose an entity that has embedded entities.
Choose Task Sector Search Operation. The Sector Search Operation dialog box opens.
Select the Allow Diversion check box if you want a deployed entity to be diverted to this task if necessary.
Select the Recover When Finished check box if you want the parent entity to wait until it recovers the deployed entity before it continues with its plan.
Specify the starting point of the search.
In the Leg box, specify the length of each leg of the search.
In the Altitude box, specify the altitude the search aircraft should fly at.
In the Air Speed box, specify the speed of the search aircraft.
Click OK.
You can assign a task to a deployable entity, that is, an embedded entity that has not been deployed yet. This implicitly deploys the entity so that it can execute the task. You can assign a task to an embedded entity in the parent’s plan or you can assign a task to a parent entity that requires it to deploy an embedded entity. The Sector Search example scripted task is an example of how to task a parent entity to deploy an embedded entity.
There is a delay of a few seconds from the time a deployment is ordered and the time it is executed.
To assign a task to a deployable entity in a parent’s plan:
Select the parent entity.
Choose Objects Plan. The Plan window opens.
Choose Embedded Entities entity Task (or Set) task (or set), where entity is one of the entities that the parent can deploy and task (or set) is one of the tasks or sets on the Task or Set menu. An appropriate dialog box for the task or set opens.
If an entity does not have embedded entities, the Embedded Entities menu is not available.
Fill out the dialog box like you would for any task or set.
Click OK. The task is added to the plan. When you run the scenario, the embedded entity gets deployed and is assigned the task or set.
Embarkation, Wait, Radio, and Other Tasks — Deploy Sonobuoys Along Route
The Deploy Sonobuoy task lets an aircraft deploy a sonobuoy for taking sonar readings. A sonobuoy is deployed as an entity. This task is available to entities that have a Sonobuoy Deployer system configured.
RPR FOM 1.0 does not support active sonar. You will not be able to create sonobuoys if they have an active sonar system.
To deploy a sonobuoy:
Select the entity.
Choose Task Deploy Sonobuoy. The Deploy Sonobuoy dialog box opens.
Select the type of sonar to use – Active or Passive.
Specify the depth at which to deploy the sonobuoy.
Click OK.
The Deploy Sonobuoys Along Route task lets an aircraft deploy sonobuoys as it moves along a route. A sonobuoy is deployed as an entity. This task is available to entities that have a Sonobuoy Deployer system configured.
RPR FOM 1.0 does not support active sonar. You will not be able to create sonobuoys if they have an active sonar system.
To deploy sonobuoys along a route:
Select the entity.
Choose Task Deploy Sonobuoys Along Route. The Deploy Sonobuoys Along Route dialog box opens.
Select the route to use.
Specify the distance between each sonobuoy.
Select the type of sonar to use – Active or Passive.
Specify the depth at which to deploy the sonobuoys.
Click OK.
Embarkation, Wait, Radio, and Other Tasks — Sonar Dip
Rotary-wing entities that have sonar can dip the sonar into water at a specified depth. Dipped sonar is not visualized in the Stealth view. The sonar is just simulated at the specified depth. Entities cannot dip sonar if they are moving faster than a set speed.
To dip sonar:
Select the entity.
Choose Task Sonar Dip. The Sonar Dip dialog box opens.
Specify the location at which to dip the sonar.
Specify how long the sonar should stay dipped.
Select the type of sonar to dip – Active or Passive.
i RPR FOM 1.0 does not support active sonar.
Specify the depth for the sonar.
Click OK.
User tasks are tasks that have been added to VR-Forces using the VR-Forces toolkit. To assign a user task, you must know the name of the task and the required values for up to four parameters.
The User Task command is not available on the Task menu unless a developer adds a controller that accepts a user task.
To assign a user task:
Select the simulation object that you want to execute the task.
Choose Task Other User Task. The User Task dialog box opens.
Type the name of the task.
Type any required parameters.
Click OK.
Embarkation, Wait, Radio, and Other Tasks — Reactive Tasks
Reactive tasks are not listed individually because they run automatically; no user action is required to execute them. This section describes the reactive tasks included with VR- Forces.
Table 30-2 lists the reactive tasks provided with VR-Forces.
Reactive Task Description
Reactive Task Description
Automatic Headlights Turn headlights and taillights on and off based on local
lighting conditions.
Auto-Enable Show Terrain Turns on Show Terrain task for object upon creation.
Avoid Other Ships Considers ship type: Aircraft carrier is higher than
fishing boat (assumes nets are out), which is higher than sailboat, which is higher than other. Will avoid surfaced submarines.
Bingo Fuel Monitor Monitors fuel on embedded entities and requests a
recovery when bingo fuel level is reached.
Evade Missile Causes fixed-wing entities to try to evade missiles. Flee From Entity Types Flees objects that match the configured entity types.
Flee From Explosion Entity will run from explosions within the specified
range.
Make Way for Emergency If an emergency vehicle that has its lights on
approaches a ground vehicle that is driving on a road, the vehicle pulls over to the side of the road.
Suppressed Crouch Forces entity to crouch when suppressed. Returns to
previous posture when no longer suppressed. Does not otherwise interrupt movement.
Suppressed Prone Forces the entity to stop and fall prone when
suppressed to level 2 or 3. Resumes movement at old posture when no longer suppressed.
Embarkation, Wait, Radio, and Other Tasks — Reactive Tasks
31. Tasks for Aggregate- Level Scenarios
This chapter describes tasks that apply to aggregate-level scenarios.
Introduction to Aggregate-Level Tasks 31-4
Attack with Anti-Air Missile 31-5
Attack with Anti-Ship Missile 31-5
Attack with Land-Attack Missile 31-6
Construct Anti-Tank Ditch 31-13
Tasks for Aggregate-Level Scenarios
Construct Fortified Area 31-19
Construct Fortified Line 31-20
Move Along Route Retrograde 31-29
Move to Location Retrograde 31-29
Move to Waypoint Retrograde 31-29
Tasks for Aggregate-Level Scenarios
Tasks for Aggregate-Level Scenarios — Introduction to Aggregate-Level Tasks
This chapter describes tasks that simulation objects in aggregate-level scenarios can run. A few tasks are identical to tasks supported by simulation objects in entity-level scenarios.
The Activate Jammer task turns on jamming for a simulation object equipped with a jamming emitter. This task has the same effect as Set Emitter - On.
To activate a simulation object’s jammer, choose Task Jamming Activate Jammer.
The Air-to-Ground Attack task requires an attack (ingress) route, an exit (egress) route, and a target point.
When the aircraft reaches the target point, it attacks with each type of HE ammunition it has. It expends all ammunition of each type. There is a 30 second delay between attacks with each ammunition type.
To specify an air-to-ground attack:
Select the entity that will attack.
Choose Task Engagement Air-to-Ground Attack. The Air-to-Ground Attack dialog box opens.
Select a target point.
Select an ingress route.
Select an egress route.
This is a multiple list dialog box. For details about how to control which list has focus, please see “Selecting Objects in Multiple List Dialog Boxes,” on page 26-8.
Click OK.
Tasks for Aggregate-Level Scenarios — Attack with Anti-Ship Missile
To order attack by fire:
Select the unit.
Choose Task Engagement Attack By Fire. The Attack By Fire dialog box opens.
Specify the location of the target entity.
Specify a location for the attacking unit.
Click OK.
This task is available to any simulation object that has anti-air missiles.
To attack a unit with an anti-air missile:
Select the simulation object that will attack.
Choose Task Engagement Attack with Anti-Air Missile. The Attack with Anti- Air Missile dialog box opens.
Select a target.
Specify the number of missiles to fire.
Click OK.
This task is available to any simulation object that has anti-ship missiles.
To attack a unit with an anti-ship missile:
Select the simulation object that will attack.
Choose Task Engagement Attack with Anti-Ship Missile. The Attack with Anti-ship Missile dialog box opens.
Select a target.
Specify the number of missiles to fire.
Click OK.
Tasks for Aggregate-Level Scenarios — Attack with Land-Attack Missile
This task is available to entities that have land-attack missiles, such as the Arleigh Burke DDG.
To attack a unit with a land-attack missile:
Select the simulation object that will attack.
Choose Task Engagement Attack with Land-Attack Missile. The Attack with Land-Attack Missile dialog box opens.
Select a target.
Specify the number of missiles to fire.
Click OK.
This task is available to entities that have torpedoes, such as the Arleigh Burke DDG.
To attack a unit with a torpedo:
Select the entity that will attack.
Choose Task Engagement Attack with Torpedo. The Attack with Torpedo dialog box opens.
Select a target.
Specify the number of torpedoes to fire.
Click OK.
When a simulation object has the Automatic Air Defense task, it automatically fires at enemy aircraft that enter the specified area. A simulation object must have an anti-air weapon, such as air-to-air missile to execute this task.
To enable automatic air defense:
Select a simulation object that has anti-air capability.
Choose Task Engagement Automatic Air Defense. The Automatic Air Defense dialog box opens.
Select the area in which the simulation object should automatically fire anti-air weapons.
Click OK.
Tasks for Aggregate-Level Scenarios — Biological Attack
When you assign a Biological Attack task, you specify the center of the area in which it will take place. The size of the area and the allowed range from the simulation object is specified in the biological weapon weapon system. You can edit these values in the Simulation Object Editor.
To execute a biological attack:
Select the simulation object that will make the attack.
Choose Task Engagement Biological Attack. The Biological Attack dialog box opens.
Click a location for the center of the area of attack or specify the coordinates.
In the Agent Type list, select the type of biological agent.
Click OK.
Tasks for Aggregate-Level Scenarios — Bomb Location
You can specify that a simulation object bomb a location. When you choose a weapon, the Bomb Location dialog box displays information about the chosen weapon (Figure 31-1).
Figure 31-1. Bomb Location dialog box
To bomb a location:
Select the simulation object that will attack.
Choose Task Engagement Bomb Location. The Bomb Location dialog box opens.
Click the location to bomb or enter the coordinates.
Specify the number of bombs to drop.
In the Weapon list, select the type of bomb to drop.
Click OK.
Tasks for Aggregate-Level Scenarios — Breach Obstacles
The Breach Obstacles task lets an engineering unit breach an obstacle so that units can pass through it. Depending on the breaching system a unit has, it may be able to breach fortifications, minefields, or ditches.
A breach line is specified with two points.
To breach an obstacle:
Select a combat engineering unit.
Choose Task Combat Engineering Breach Obstacles. The Breach Obstacles dialog box opens.
Click Define. The cursor changes to draw mode and the Create Breach dialog box opens or becomes available.
Draw a two-point line to specify where to create the breach. After the second click the line disappears. This is because it is not being created now. The dialog box button now says Edit and the text next to it says Defined.
Click OK.
Tasks for Aggregate-Level Scenarios — Change MOPP Level
Supported MOPP levels are as follows:
MOPP Level 0 — Protective mask carried. Suit, gloves, and boots accessible/avail- able.
MOPP Level 1 — Suit worn. Mask, gloves and boots carried.
MOPP Level 2 — Suit and boots worn. Gloves and mask carried.
MOPP Level 3 — Suit, boots and mask worn. Gloves carried.
MOPP Level 4 — All protection worn.
Changes to MOPP level do not take place immediately. (To change the MOPP level immediately, use Set MOPP Level.) Increasing the MOPP level degrades a simulation object’s speed and combat effectiveness. Increasing the MOPP level does not remove existing contamination, but prevents most NBC contamination from harming the simulation object.
To change a unit’s MOPP level:
Select the unit.
Choose Task Change MOPP Level. The Change MOPP Level dialog box opens.
Specify a new MOPP level.
Click OK.
Tasks for Aggregate-Level Scenarios — Chemical Attack
You can set a simulation object’s posture to one of the following:
Travel
Reconnaissance
Hasty attack
Deliberate attack
Hasty defense
Changes to posture take place over time. To change posture immediately, use Set Posture.
To change a simulation object’s posture:
Select the simulation object.
Choose Task Change Posture. The Change Posture dialog box opens.
Specify a new posture.
Click OK.
The Chemical Attack task lets a unit create an area contaminated with chemical agents.
When you assign a Chemical Attack task, you specify the center of the area in which it will take place. The size of the area and the allowed range from the unit is specified in the chemical weapon weapon system. You can edit this value in the Simulation Object Editor.
To execute a chemical attack:
Select the unit that will make the attack.
Choose Task Engagement Chemical Attack. The Chemical Attack dialog box opens.
Click a location for the center of the area of attack or specify the coordinates.
In the Agent Type list, select the type of chemical agent.
Click OK.
Tasks for Aggregate-Level Scenarios — Construct Abatis
Combat engineering units can construct abatises. An abatis is specified as a point.
You can create abatises directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this obstacle.
To construct an abatis:
Select a combat engineering unit.
Choose Task Combat Engineering Construct Abatis. The Construct Abatis dialog box opens (Figure 31-2). The Location is specified as “Not defined”.
Click Define. The Create Abatis dialog box opens (Figure 31-3).
Click where you want to locate the abatis.
In the Create Abatis dialog box, click OK.
Optionally, specify a name for the abatis.
In the Construct Abatis dialog box, click OK.
Tasks for Aggregate-Level Scenarios — Construct Anti-Tank Ditch
You can create anti-tank ditches directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this obstacle.
To construct an anti-tank ditch:
Select a combat engineering unit.
Choose Task Combat Engineering Construct Anti-Tank Ditch. The Construct Anti-Tank Ditch dialog box opens (similar to Figure 31-2). The Location is speci- fied as “Not defined”.
Click Define. The Create Anti-Tank Ditch dialog box opens and the cursor changes to draw mode.
Click to specify the vertexes of the line as you would when creating any linear object, or add points in the dialog box and click Create.
Optionally, specify a name for the ditch.
Click OK.
Tasks for Aggregate-Level Scenarios — Construct Barbed Wire
Combat engineering units can construct barbed wire obstacles. Barbed wire is specified as a line.
You can create barbed wire directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this obstacle.
To construct barbed wire:
Select a combat engineering unit.
Choose Task Combat Engineering Construct Barbed Wire. The Construct Barbed Wire dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.
Click to specify the vertexes of the line as you would when creating any linear object.
Optionally, specify a name for the barbed wire.
In the Construct Barbed Wire dialog box, click OK.
Combat engineering units can construct barricades. A barricade is specified as a line.
You can create barricades directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this obstacle.
To construct a barricade:
Select a combat engineering unit.
Choose Task Combat Engineering Construct Barricade. The Construct Barri- cade dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.
Click to specify the vertexes of the line as you would when creating any linear object.
Optionally, specify a name for the barricade.
In the Construct Barricade dialog box, click OK.
Tasks for Aggregate-Level Scenarios — Construct Booby Trap
Combat engineering units can construct berms. A berm is specified as a line.
You can create berms directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this obstacle.
To construct a berm:
Select a combat engineering unit.
Choose Task Combat Engineering Construct Berm. The Construct Berm dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.
Click to specify the vertexes of the line as you would when creating any linear object.
Optionally, specify a name for the berm.
In the Construct Berm dialog box, click OK.
You can create booby traps directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this object.
To construct a booby trap:
Select a combat engineering unit.
Choose Task Combat Engineering Construct Booby Trap. The Construct Booby Trap dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.
Click where you want to locate the booby trap or type the coordinates in the dialog box and click OK.
Optionally, specify a name for the booby trap.
Tasks for Aggregate-Level Scenarios — Construct Booby Trap
Click OK.
Tasks for Aggregate-Level Scenarios — Construct Bridge
Combat engineering units can construct bridges. A bridge is specified as a two-point line.
You can create bridges directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this object.
To construct a bridge:
Select a combat engineering unit.
Choose Tasks Combat Engineering Construct Bridge. The Construct Bridge dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.
Click Define. The Create Bridge dialog box opens and the cursor changes to draw mode.
Click on the terrain to specify the start and end vertices of the bridge.
Right-click to finish the bridge, or click Create in the Create Bridge dialog box.
Optionally, specify a name for the bridge.
Click OK.
Tasks for Aggregate-Level Scenarios — Construct Dry Gap
Combat engineering entities can construct dry gaps. A dry gap is a type of ditch. (Use Improve Ditch and Destroy Ditch to continue building a dry gap or destroy it.)
You can create dry gaps directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this object.
To construct a dry gap:
Select a combat engineering unit.
Choose Task Combat Engineering Construct Dry Gap. The Construct Dry Gap dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.
Click Define. The Create Dry Gap dialog box opens and the cursor changes to draw mode.
Click to specify the vertices of the dry gap.
Right-click to finish the dry gap, or click Create in the Create Dry Gap dialog box.
Optionally, specify a name for the dry gap.
Click OK.
Tasks for Aggregate-Level Scenarios — Construct Fortified Area
You can create fortifications directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this object.
To construct a fortified area:
Select a combat engineering unit.
Choose Task Combat Engineering Construct Fortified Area. The Construct Fortified Area dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.
Click Define. The Create Fortified Area dialog box opens and the cursor changes to show an area.
Click where you want to locate the southwest corner of the area or type the coordi- nates in the dialog box and click Create.
Optionally, specify a name for the area.
Click OK.
Tasks for Aggregate-Level Scenarios — Construct Fortified Line
Combat engineering entities can construct fortified lines.
You can create fortifications directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this object.
To construct a fortified line:
Select a combat engineering unit.
Choose Task Combat Engineering Construct Fortified Line. The Construct Fortified Line dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.
Click Define. The Create Fortified Line dialog box opens and the cursor changes to draw mode.
Click to specify the vertexes of the line as you would when creating any linear object, or add points in the dialog box and click Create.
Optionally, specify a name for the line.
Click OK.
Tasks for Aggregate-Level Scenarios — Construct Minefield
Combat engineering entities can construct volcano minefields. Minefields are fixed size rectangles.
You can create minefields directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this obstacle.
To construct a minefield:
Select a combat engineering unit.
Choose Task Combat Engineering Construct Minefield. The Construct Mine- field dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.
Click where you want to locate the southwest corner of the minefield or type the coordinates in the Create Minefield (Volcano) dialog box and click Create.
Optionally, specify a name for the minefield.
In the Construct Minefield dialog box, click OK.
Tasks for Aggregate-Level Scenarios — Construct Strong Point
You can create strong points directly from the Hazards/Obstacles Palette. This task is used when you want a unit to construct this object.
To construct a strong point:
Select a combat engineering unit.
Choose Task Combat Engineering Construct Strong Point. The Construct Strong Point dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.
Click Define. The Create Strong Point dialog box opens and the cursor changes to show a box.
Click where you want to locate the southwest corner of the box or type the coordi- nates in the dialog box and click Create.
Optionally, specify a name for the strong point.
Click OK.
The Deactivate Jammer task turns off jamming for a simulation object equipped with a jamming emitter. This task has the same effect as Set Emitter - Off.
To deactivate a simulation object’s jammer, choose Task Jamming Deactivate Jammer.
Tasks for Aggregate-Level Scenarios — Destroy Explosive
When you task an engineering unit to destroy a bridge, it consumes its Explosives resource. As the unit attacks the bridge, the bridge’s completeness percentage decreases. When the completion percentage reaches zero, the bridge is removed from the scenario.
To destroy a bridge:
Select a combat engineering unit.
Choose Tasks Combat Engineering Destroy Bridge. The Destroy Bridge dialog box opens.
Select the bridge you want to destroy.
Click OK.
To destroy a ditch:
Select a combat engineering unit.
Choose Tasks Combat Engineering Destroy Ditch. The Destroy Ditch dialog box opens.
Select the ditch you want to destroy.
Click OK.
The Destroy Explosive task lets a unit destroy a booby trap or unexploded ordnance.
To destroy explosives:
Select a combat engineering unit.
Choose Tasks Combat Engineering Destroy Explosive. The Destroy Explosive dialog box opens.
Select the booby trap or unexploded ordnance you want to destroy.
Click OK.
Tasks for Aggregate-Level Scenarios — Destroy Fortification
When you task an engineering unit to destroy a fortification, it consumes its Explosives resource. As the unit attacks the fortification, the fortification’s completeness percentage decreases. When the completion percentage reaches zero, the fortification is removed from the scenario.
To destroy a fortification:
Select a combat engineering unit.
Choose Tasks Combat Engineering Destroy Fortification. The Destroy Fortifi- cation dialog box opens.
Select the fortification you want to destroy.
Click OK.
To destroy an obstacle:
Select a combat engineering unit.
Choose Tasks Combat Engineering Destroy Obstacle. The Destroy Obstacle dialog box opens.
Select the obstacle you want to destroy.
Click OK.
For details, please see “Disembark,” on page 30-3.
For details, please see “Disembark All,” on page 30-3.
For details, please see “Embark,” on page 30-4.
Tasks for Aggregate-Level Scenarios — Improve Booby Trap
To fire FASCAM:
Select a simulation object that can execute this task.
Choose Tasks FASCAM. The FASCAM dialog box opens (similar to Figure 31-2). The Location is specified as “Not defined”.
Click Define. The Create Minefield (ADAM-RAAM) dialog box opens and the cursor changes to show a minefield.
Click where you want to locate the southwest corner of the minefield or type the coordinates in the Create Minefield (ADAM-RAAM) dialog box and click Create.
Optionally, specify a heading.
In the FASCAM dialog box, click OK.
The Halt Movement task causes a simulation object to stop moving.
To halt a simulation object’s movement:
Select the simulation object.
Choose Tasks Movement Halt Movement. Movement stops immediately.
To improve a booby trap:
Select a combat engineering unit.
Choose Task Combat Engineering Improve Booby Trap. The Improve Booby Trap dialog box opens.
Select the booby trap that you want to improve.
Click OK.
Tasks for Aggregate-Level Scenarios — Improve Breach
To improve a breach:
Select a combat engineering unit.
Choose Tasks Combat Engineering Improve Breach. The Improve Breach dialog box opens.
Select the breach you want to improve.
Click OK.
To improve a bridge:
Select a combat engineering unit.
Choose Tasks Combat Engineering Improve Bridge. The Improve Bridge dialog box opens.
Select the bridge you want to improve.
Click OK.
The Improve Ditch task lets a combat engineering unit improve an incomplete anti- tank ditch. When you improve a ditch it gets improved to as complete a strength level as the unit can bring it to. This task can be assigned to a unit to assist another unit that is creating a ditch.
To improve a ditch:
Select a combat engineering unit.
Choose Task Combat Engineering Improve Ditch. The Improve Ditch dialog box opens.
Select the ditch that you want to improve.
Click OK.
Tasks for Aggregate-Level Scenarios — Improve Obstacle
The Improve Fortification task lets a unit improve an incomplete fortification area, line, or strong point. When you improve a fortification it gets improved to as complete a strength level as the unit can bring it to. This task can be assigned to a unit to assist another unit that is creating a fortification.
To improve a fortification:
Select a combat engineering unit.
Choose Task Combat Engineering Improve Fortification. The Improve Fortifi- cation dialog box opens.
Select the fortification that you want to improve.
Click OK.
To improve an obstacle:
Select a combat engineering unit.
Choose Task Combat Engineering Improve Obstacle. The Improve Obstacle dialog box opens.
Select the obstacle that you want to improve.
Click OK.
Tasks for Aggregate-Level Scenarios — Indirect Fire
If the blast effect radius of the munitions being fired is less than the sheaf radius, the attack strength is reduced by the ratio of the areas of the blast circle to the sheaf circle. For example, if the sheaf radius is 100 and the blast effect radius is 50, the ratio of the areas is 1:4, so the attack strength would be 25% of the full value.
To specify indirect fire for a unit:
Select the unit.
Choose Task Engagement Indirect Fire. The Indirect Fire dialog box opens.
Select the point on which you want to center the indirect fire.
In the Weapon list, select the weapon you want to use. Its characteristics are displayed.
In the Number of Attacks box, specify how many attacks to make.
Click OK.
Tasks for Aggregate-Level Scenarios — Move to Waypoint Retrograde
For details, please see “Move Along Route,” on page 27-13.
For details, please see “Move to Location,” on page 27-16.
For details, please see “Move to Waypoint,” on page 27-20.
Move to Waypoint Retrograde is the same as Move to Waypoint, except that the simu- lation object does not change its heading to the direction of movement. It maintains the heading at the start of movement or a heading necessary for defensive operations. See the Move to Waypoint task for the procedure for this task.
Tasks for Aggregate-Level Scenarios — Nuclear Attack
The Nuclear Attack task lets a simulation object create an area contaminated with nuclear radiation.
When you assign a Nuclear Attack task, you specify the center of the area in which it will take place. The size of the area and the allowed range from the simulation object is specified in the nuclear weapon weapon system. You can edit this value in the Simula- tion Object Editor.
To execute a nuclear attack:
Choose Task Engagement Nuclear Attack. The Nuclear Attack dialog box opens.
Click a location for the center of the attack area or specify the coordinates.
In the Agent Type list, select the type of radiation.
Click OK.
For details, please see “Patrol Route,” on page 27-23.
For details, please see “Patrol Between,” on page 27-24.
To send an NBC report:
Select a simulation object.
Choose Task Send NBC Report. The Send NBC Report dialog box opens.
Select the contamination area for which to send a report.
Specify the Engagement Result. This is any text that you want to accompany the report.
Click OK.
Tasks for Aggregate-Level Scenarios — Wait Tasks
To send an obstacle report:
Select a simulation object.
Choose Task Send Obstacle Report. The Send Obstacle Report dialog box opens.
Select the obstacle for which to send a report.
Specify the Engagement Result. This is any text that you want to accompany the report.
Click OK.
For details, please see “Send Radio Set,” on page 30-7.
For details, please see “Send Radio Task,” on page 30-9.
For details, please see “Send Text Message,” on page 30-10.
For details, please see “User Task,” on page 30-18.
For details, please see “Wait Tasks,” on page 31-31.
Tasks for Aggregate-Level Scenarios — Background Process List
Background processes are not described in detail because they run automatically; no user action is required to execute them.
Table 31-1 lists the background tasks provided. These tasks are only available for units in AggregateLevel.sms.
Table 31-1: Background processes
Background Process Description
Background Process Description
Attack Enemies Determines when to begin and stop attacking enemies.
Calculate Maximum Speed Modifier
Calculates a modifier that is applied to the maximum possible speed of a unit to modify its movement rate.
Halt When Engaged Stop moving when attacking a hostile simulation object.
Make EW Attack If a jammer system is turned on, attack all non-friendly
simulation objects within range of the jammer. The simu- lation object attacks continuously.
Manage Sensors Manages the state of a simulation object’s sensors.
Perform Attrition Determines when a unit is being attacked and modifies its
health based on the current attrition rate.
Put on MOPP Gear If a simulation object has MOPP gear, when it enters a
hazardous area, it stops and changes to MOPP level 4.
Receive Construction Allows an engineering object to receive construction from
other simulation objects.
Resize Footprints Updates the size of a simulation object’s physical and
sensor footprints.
Update Combat Effective- ness
Updates the combat effectiveness state of a simulation object.
Update EW Degradation Processes jamming interactions and computes the level
of degradation in communications and radar from these attacks.
Use Supplies Uses supplies based on the simulation object’s current
activities.
32. Creating Scripted Tasks and Sets
VR-Forces lets you create new tasks and set data requests by writing scripts. You do not need to know C++ or have a developers license to write these scripts. This chapter explains how to create and edit script meta data and how to organize and enable scripts. Chapter 33, Writing Scripts explains how to write script code.
Background Process Scripts 32-5
The Lua Scripting Language 32-5
Specifying the Script ID 32-11
Specifying an Extended Name 32-12
Specifying a Short Description 32-12
Specifying Script Parameters 32-13
Specifying a Menu Location 32-17
Specifying Action Categories 32-18
Configuring a Script’s Availability to a Simulation Object Type 32-19
Specifying Equivalent Scripts for a Toolbar Button 32-23
Specifying the Programming Language for a Script 32-25
Creating Background Processes 32-29
Creating Scripted Tasks and Sets
Filtering the List of Scripts 32-31
Organizing Scripts into Folders 32-31
Adding Scripts to a Folder 32-32
Removing a Script from a Folder 32-32
Exporting and Importing Scripts 32-32
Importing a Script Package 32-33
Creating a System Script 32-35
Including System Scripts on the Task and Set Menus 32-35
Specifying a Script Editor 32-37
The script capability in VR-Forces allows you to create new tasks and set data requests for simulation objects without using the VR-Forces Toolkit and C++ API. Scripts use the Lua programming language. The actions that simulation objects can carry out are still limited to the basic C++ tasks provided by VR-Forces. However, since Lua is a full- featured scripting language, it is far more powerful than the language used to create plans and you can be much more creative in how you use the basic tasks. In addition to functions for tasks and sets, Lua scripts can make many types of calls to the simulation engine to get simulation object status or other simulation data. Scripts can also set some simulation data.
VR-Forces supports the following types of scripts:
Task. Scripted tasks can be listed on the Task menu and used as independent tasks or in plans just like C++ tasks.
Reactive task. A reactive task monitors the simulation and gets activated when the conditions set in the script become true. Reactive tasks are enabled or disabled for simulation objects through the GUI.
Background process. A background process runs continuously from the time a simulation object is created. There is no user interface for assigning background processes to simulation objects. Their use is based entirely on the scripting process.
Set data request. Set data request scripts change simulation object state without interrupting the current task.
Although creation of scripts requires that you have some programming skills, you do not need to know C++, use a compiler, or use the VR-Forces APIs to write these scripts.
Creating Scripted Tasks and Sets — Introduction to Scripts
From a Lua script you can:
Create and delete simulation objects and tactical graphics.
Set weather and environment state.
Get simulation object state, such as:
Aggregation
Location
Embarkation
Type
Force
Damage state
Velocity.
Monitor and set simulation object resources.
Get simulation object sensor contacts.
Task other simulation objects.
Subtask self.
Send Set Data Request messages.
Test terrain:
Get terrain height.
Check line of sight.
Find feature data.
VR-Forces includes a text editor (SciTE) to use as the default script editor. You can configure VR-Forces to use a different editor if you want to. For details, please see “Specifying a Script Editor,” on page 32-37.
Scripted tasks can be added to the Task menu and are treated just like the tasks that are built into VR-Forces.
When you create a scripted task, you can specify input parameters. When you assign the task to a simulation object, either from the Task menu or in a plan, VR-Forces builds a dialog box for the task that includes all of the parameters specified for the script.
When you create a scripted set, you can specify input parameters. When you assign the set to a simulation object, either from the Set menu or in a plan, VR-Forces builds a dialog box for the set that includes all of the parameters specified for the script.
A scripted set cannot issue tasks to the entity that executes it or to any other entity.
Reactive tasks monitor a simulation and get activated when the conditions set in the script become true. Reactive tasks are not added to the Task menu. In most respects the process for creating and writing reactive tasks is the same as creating and writing all scripts. Assume that all details about scripts apply to reactive tasks unless noted other- wise. For conceptual details about reactive tasks, please see “Reactive Tasks,” on
page 26-12.
The background process is a script that runs in the background for the simulation object types for which it was written. Since a background process has no user interface, it does not have any input parameters. When you create a background process, you specify the simulation object types for which it is available and you write the script.
To create a new script, you specify the metadata for the script and write the script code. A script’s metadata specifies the script’s name, where it will be placed on a menu, and its parameters, if any. Specifying metadata may be an iterative process, particularly the parameters, which may change as you write the code for the script. However, the minimum first step in creating a script is to specify a name for the script and add it to the list of scripts. Once you do this, you can edit the metadata and the code as needed until you have completed the script to your satisfaction.
All new scripts are created as scenario scripts. If you want to create a new system script, you save the scenario script as a system script. For details, please see “Creating a System Script,” on page 32-35.
To create a script, you must have a scenario open. This is true even if you plan to create a system script rather than a scenario script.
To create a new script:
Open a scenario. (If you want to create a system script, you must create it in the context of a scenario. Then you will promote it to a system task.)
Choose Simulation Scripts. The Scripts dialog box opens (Figure 32-1).
Figure 32-1. Scripts dialog box
If you have a folder hierarchy and want to create the script in a particular folder, select the folder. (For more information, please see “Organizing Scripts into Folders,” on page 32-31.)
Choose Script New Script. The New Script dialog box opens (Figure 32-2).
In the Script Type list, select the type of script you are creating (Task, Reactive Task, Set, or Background Process). The dialog box displays the correct set of meta- data for the type of script you chose.
Complete the fields in the dialog box. They are described in Table 32-1 and in following sections.
Input Field Description
Input Field Description
Script ID A unique name for the script. VR-Forces generates a default name, but you will probably want to change it to something meaningful. It is your responsibility to make sure that it is unique. Please see “Specifying the Script ID,” on page 32-11 for details.
Script Type One of the following:
Task. A scripted task that would typically be accessed through the Task menu.
Reactive Task. A task that executes in response to specific conditions.
Background Process. A process that executes continuously in the background.
Set. A set data request that changes simulation object state.
The fields on the New Script dialog box vary based on which type of task is being created.
Language Specify Lua if you are writing a Lua script. Specify C++ if you have written a new task controller and want to use the script interface to create the GUI portion of the task. (Does not apply to reactive tasks and background processes.) For more information, please see “Specifying the Programming Language for a Script,” on page 32-25.
Name The text that will be added to the Task or Set menu for this script.
Extended Name An alternative name to use on context-insensitive task
or set lists if more than one task or set has the same name.
Short Description The text to use for this script in a Plan window.
Description A description of what the script does. This text is displayed on the dialog box. (Optional)
Action Categories For tasks, specifies the categories of tasks that this
scripted task will interrupt. (In other words, action categories manage task concurrency. For details about concurrent tasks, please see “Concurrent Task Execution,” on page 26-5.) (Does not apply to back- ground processes or sets.)
Table 32-1: Script metadata
Input Field Description
Input Field Description
Tool Tip Text for a tooltip when the script is selected on a menu. (Optional) (Does not apply to reactive tasks and background processes.)
Menu Icon The icon to display next to the name on a menu.
Please see “Specifying a Menu Icon,” on page 32-11 for details. (Optional) (Does not apply to reactive tasks and background processes.)
Parameters The input parameters that the task or set requires.
Please see “Specifying Script Parameters,” on
page 32-13 for details. (Optional) (Does not apply to background processes.)
Make Available Based on Entity Type
If selected, the script is available to the simulation object types in the Valid for Entity Types list.
Valid for Entity Types The simulation object types that can use this script.
Editable only if Make Available Based on Entity Type is selected. This entry affects the context sensitivity of the Task or Set menu. Please see “Specifying the Valid Simulation Object Types for a Script,” on
page 32-20 for details. Default: All.
Make Available Based on Behavior Sets
Make Available to Global Plans
If selected, the script is available to the simulation object only if the selected behavior set is assigned to its force.
If selected, the script is available on the Task or Set menu in global plans.
Behavior Sets Select each Behavior Set that you want this script to
be part of. You can also assign scripts to Behavior Sets in the Edit Behavior Sets dialog box. For details about Behavior Sets, please see “Using Behavior Sets to Manage Scripts,” on page 26-19.
Show on Top Level Right Click Menu
Select to show the task or set on the top level of the right-click menu. This setting can be in addition to showing the script on the Task or Set menu.
Show Task on Task Menu Select to show the scripted task on the Task menu.
Clear to hide the task. (You might want to write a script that will be used by other scripts, but which you do not want a user to assign directly to a simula- tion object.) (For task scripts only.)
Show Set on Set Menu Select to show the scripted set data request on the
Set menu. Clear to hide the set. (You might want to write a script that will be used by other scripts, but which you do not want a user to assign directly to a simulation object.) (For set scripts only.)
Table 32-1: Script metadata
Input Field Description
Input Field Description
Menu Location The location on the Task or Set menu where this
script will be listed. Please see “Specifying a Menu Location,” on page 32-17 for details. (Does not apply to reactive tasks and background processes.)
Show Task on Task Toolbar
Select to add this task to the Task Toolbar. The toolbar displays the name of the script. If you want to display an icon, select a Task menu icon for this task, as described in “Specifying a Menu Icon,” on
page 32-11. (Tasks only.)
Show Set on Set Toolbar Select to add this set data request to the Set Toolbar.
The toolbar displays the name of the script. If you want to display an icon, select a menu icon for this task, as described in “Specifying a Menu Icon,” on page 32-11. (Sets only.)
Toolbar Location The location on a toolbar for this script. You can
assign more than one script to a toolbar button. For details, please see “Specifying Equivalent Scripts for a Toolbar Button,” on page 32-23.
Enabled by Default Reactive tasks only. If selected, the reactive task is
automatically enabled for all supported simulation object types.
Default Priority Reactive tasks only. The priority for this task. For
information about the effect of reactive task priority, please see “Reactive Tasks,” on page 26-12.
View Like Priorities Reactive tasks only. Displays a list of the reactive
tasks that are valid for this task’s simulation object types and action categories. This helps you decide what priority you want to give to the reactive task you are creating or editing.
Optionally, click Preview to see the dialog box that the script will create.
Optionally, click Edit Script to begin writing the code for this script.
Click Add. The script is added to the list in the Scripts window.
To save the script task as part of the scenario, save the scenario.
Write the code for the script. For details, please see Chapter 33, Writing Scripts.
Each script must have a unique ID. VR-Forces generates a default ID, but it does not contain meaningful text. Therefore, you may want to change the ID.
!
!
The script ID is used internally by VR-Forces to manage how a script is executed. If a script is used in a plan, it is referenced by its script ID. If you change the ID, you must ensure that it is unique. You cannot edit the ID of a system script.
To specify the script ID:
In the New Script (or Edit Script) dialog box, click the button to the right of the Script ID. The New Script ID dialog box opens.
Type the ID you want to use.
Click OK.
If you want to put an icon on the Task or Set menu next to the menu text, you can specify one. (Does not apply to reactive tasks and background tasks.)
To specify a menu icon:
Click the Add button ( ) next to the Menu Icon label. The Select Menu Icon dialog box opens.
Browse the directory structure and select the icon that you want to use.
Click Open.
To remove a menu icon for a script, click the Remove button ( ) next to the Menu Icon label.
Sometimes a script needs to be implemented differently for different types of simula- tion objects. To accomplish this you can write different scripts for each type of simula- tion object, but give the task the same name. The scripts are distinguished by their script IDs and VR-Forces picks the correct script using context sensitivity. For example, you might have two scripts with the IDs Move_To_Waypoint_Entity and Move_To_Waypoint_Unit. Both would have the name Move to Waypoint. When you wanted to give a Move to Waypoint task, you would select the simulation object and choose Move to Waypoint from the Task menu. VR-Forces would pick the correct version of the task.
The one problem with this system is that in cases where VR-Forces does not enforce context-sensitivity of task or set lists, you would end up with two tasks called Move to Waypoint and no way to know which was the correct one to use for the simulation object that you wanted to assign the task to. The extended name solves this problem. If you specify an extended name for a script, it is used between scripts that use the same task or set name.
When you add a scripted task or set data request to a plan, the entry in the Plan window can be lengthy and cryptic. It often includes information, such as location values that are not easily understood or put to use by a reader. The Short Description field for a script lets you specify a short, meaningful description to be used in the Plan window.
The description can include variable information. To include variable data, use the syntax $variable_name, where variable_name is one of the variables for the script. For example, the default listing for the Move to Waypoint (Plan Along Roads) task is:
move-to-waypoint-path-plan: destination=Waypoint1
If you specify a short description of Move to $destination (Plan Path), the listing in the Plan window would be:
Move to Waypoint1 (Plan Path)
Aggregate Formation. Provides a list of formations for units.
Altitude MSL. Altitude above mean sea level.
Altitude Rate Change. Lets you specify the rate at which an aircraft changes alti- tude.
Animated Movement. Lets you assign an animated movement to an entity.
Bomb Resource. Creates a list of bomb resources.
Boolean. Creates a check box.
Choice (List). Specifies choices presented in a drop-down list.
Choice (Option Button). Specifies choices presented as option (radio) buttons.
DI-Guy Animation. Lets you select a DI-Guy animation.
DI-Guy Appearance. Lets you select a DI-Guy appearance.
Date/Time. Specifies the date and time.
Depth MSL. Specifies the depth below mean sea level.
Direct Fire Weapon.
Distance. Specifies a distance.
Embedded Entity. Lets you select an embedded entity to deploy.
Emitter. Entity emitter ID.
Entity Type. Lets you specify one object type enumeration.
Entity Types. Lets you specify a list of object type enumerations.
Force. Specifies the force.
Heading. Heading, in degrees.
Indirect Fire Weapon. Specifies an indirect fire weapon.
Integer. A whole number.
Location (with altitude). Vector description of a location, in geocentric, including altitude.
Location (without altitude). Vector description of a location, in geocentric, altitude not included.
Munition Resource. Creates a list of munitions.
Naval Mine Resource. Specifies a naval mine resource.
New Tactical Graphic. Lets you define a tactical graphic.
Observer Mode. Specifies an observer mode, for example, Stealth, IG, or XR.
Observer Saved View. Specifies a saved view.
Offset Location. Specifies an offset to the side, behind, and above, as in the Follow Entity task.
Real. A floating point decimal number.
Resource. Creates a list of available resources.
Separator. Lets you put a separator in the generated dialog box. This is just for formatting purposes.
Simulation Object (Single). Lets you select one simulation object in a list window.
Simulation Objects (Multiple). Lets you select multiple simulation objects in a list window.
Speed. Any kind of rate, such as speed, climb rate, and so on.
String. An alphanumeric string.
Time. Time in days:hours:minutes:seconds.
Topographic Orientation. Specifies orientation in topographic coordinates.
Turn Rate. Turn rate in radians/second.
Weapon. Specifies a weapon.
If a script does not have any input parameters, it executes as soon as it is assigned to a simulation object, like the Wait command does.
To specify a parameter for a script:
Click the Add button ( ) above the Parameters list. The Add Parameter dialog box opens (Figure 32-3).
Select the type of parameter from the Type list. If appropriate, the dialog box redis- plays to request the details required for the variable type you selected.
Fill out the fields as follows:
All of the parameters have the following fields:
Parameter Name. The name to be used by the Lua script for this parameter. For example, if you give a parameter the name taskDestination, in the Lua code for the script, the parameter will be accessed as taskParameters.taskDestination.
Label. This is the text used on the dialog box that is generated for the task. If you leave this field blank, the parameter name is used.
Tool Tip. Optional text for a tool tip.
Indent Level. The number of pixels to indent the parameter on the task dialog box. This allows you to apply some formatting to the dialog box.
Visible check box. Specifies that the parameter be included on the script dialog box. (You might want a parameter to be available in the code, but not have it set by a user when the script is assigned.)
Many parameters let you specify a default value or state.
Some parameters let you specify a range for the acceptable values:
Range Bottom. The lowest acceptable value for this parameter.
Range Top. The highest acceptable value for this parameter.
The Boolean parameter type lets you create a check box. You can specify that the default be checked or unchecked.
For details about adding choices to a Choice parameter, please see “Specifying Choices for the Choice Parameters,” on page 32-15. For details about adding cate- gories to a filtered list, please see “Specifying Categories for a Simulation Object,” on page 32-16.
The Choice parameters require a list of choices, which get added to the dialog box as option buttons or as a list. You can add choices, edit them, and delete them.
To add a choice:
Click the Add Parameter button ( ) on the Choice Box Values line. The New Choice dialog box opens.
Type the text for the choice.
Click OK.
Repeat this procedure for each choice that you want to have available. (The last choice added becomes the default choice.)
The Simulation Object parameter lets you build a list of categories on which to filter the display of simulation object types in a dialog box.
To add a category to the simulation object list:
Click the Add Parameter button ( ) on the Filters line. The Choose Filter dialog box opens.
Select a filter from the Filters list.
Click OK.
Repeat the procedure to add as many filters as you want.
Editing the Category List for a Simulation Object Parameter
You can edit the list of filter categories for a Simulation Object parameter. The edit operation is essentially a replacement of the current category with a new one. You can achieve the same effect by deleting the current category and adding a new one.
To edit the list of filter categories in a Simulation Object parameter:
Select the parameter you want to edit in the Parameters list on the New Scripted Task dialog box.
Click the Edit button 
). The Script Variable dialog box opens.
In the Filters list, select the filter that you want to edit.
Click the Edit button 
). The Choose Filter dialog box opens.
Select the filter category that you want to use.
Click OK. The original category is removed and the new one is added.
To delete a category from a Simulation Object parameter:
Select the parameter you want to edit in the Parameters list on the New Scripted Task dialog box.
Click the Edit button 
). The Script Variable dialog box opens.
In the Filters list, select the filter that you want to delete.
Click the Delete button ( ). The category is removed from the list.
Scripted tasks get added to the Task menu unless you specify that they not be shown (by clearing the Show Task on Task Menu check box). Scripted set data requests get added to the Set menu. The default location is the top level of the menu. However, you will probably want to organize your tasks and sets using the submenus provided by VR- Forces or in newly created submenus. The New Script dialog box displays the menu under which the script is placed. It does not show the full path from the top level menu.
You can also add a scripted task or set to the top level right-click menu. The script can be listed in both places.
When you add a script to a menu, it does not appear on the menu until you reload the scenario.
To specify a menu location for a script:
On the Menu Location line, click the Edit button 
). For task scripts, the Select Location on Task Menu dialog box opens (Figure 32-1). For set scripts, the Select Location on Set Menu dialog box opens. The two dialog boxes are functionally identical.
Figure 32-4. Select Location on Task Menu dialog box
To add the script to an existing submenu:
Expand the submenu on which you want to put the script.
Select the menu item that you want the new script to be next to.
To put the new script above the selected menu item, select the Add Before Selected option. To put the new script below the selected menu item, select the Add After Selected option.
Click OK.
To create a new submenu for the script:
Select the submenu next to where you want to add the new submenu.
To add the new menu before the selected submenu, click Add Menu Before. To add the new menu after the selected submenu, click Add Menu After. The New Menu Name dialog box opens.
Type a name for the new submenu.
Click OK.
Add the script to the new submenu using the procedure in step 2.
Some VR-Forces tasks can run at the same time as other tasks, while some are mutually exclusive. This is called task concurrency. (For details about concurrent tasks, please see “Concurrent Task Execution,” on page 26-5.) The C++ tasks provided with VR-Forces are organized in groups to help manage concurrency. They are configured in
./data/simulationModelSets/<model_set>/vrfSim/taskRules/default-task-rules.tsk.
In the New Script dialog box, these groups are represented as action categories. The action categories displayed in the New Script dialog box are configured in ./data/simula- tionModelSets/<model_set>/vrfSim/taskRules/actionCategories.tsk. (For details about configuring action categories, please see “Configuring Action Categories,” on
page 26-36.)
When you create or edit a scripted task you can specify which groups of tasks the new task can run concurrently with and which it will interrupt. By default, the Movement category is selected, which means that if you do not change the setting, the new task will interrupt movement tasks.
To specify which tasks a scripted task will interrupt, in the Action Categories list, select the categories to interrupt. For example, if the new task involves movement, you probably want it to interrupt other movement tasks, so you would select the Movement category check box. If it is a new type of message task, you probably want to let it run concurrently with movement tasks, so you would clear the Move- ment category check box.
Scripts can be available to a simulation object based on the following criteria:
The script is available for certain simulation object types. For details, please see “Specifying the Valid Simulation Object Types for a Script,” on page 32-20.
The script is part of a Behavior Set. For details, please see “Specifying Availability by Behavior Set,” on page 32-21.
A task or set is specified in a system definition. (For example, the Naval Mine Sweep task is available to entities with a Naval Mine Sweep system.) This state is not shown in the Edit Script dialog box. For details, please see “Specifying a Scripted Task or Set in a System Definition,” on page 32-21.
The default setting for new scripts is that they are available to all simulation objects.
Availability by simulation object type and by Behavior Set is configured in the New Script and Edit Script dialog boxes. Table 32-2 shows the interaction of these settings.
Table 32-2: Scripted task availability
Available by Entity Type
Available by Behavior Set
Availability
Available by Entity Type
Available by Behavior Set
Availability
The script is available only to those simulation object types listed.
The script is available to all simulation objects, but only if one of the selected behavior sets is applied to the simulation object’s force.
The script is available to the specified simulation object types, but only if one of the selected behavior sets is applied to the simulation object’s force.
You can restrict a script to specific simulation object types. If you do this, the script will not appear on the Task or Set menu when you select a simulation object for which it is not valid. Just as with built-in VR-Forces tasks and sets, there are cases, such as for global plans, where VR-Forces cannot determine the simulation object context and the script will be available on the menu even though it is not appropriate to the simulation object that you selected. In those cases it is up to you to know that a task or set is valid.
To specify the valid entity types for a script:
Select the Make Available Based on Entity Type check box.
Click the Add button ( ) on the Valid for Entity Types line. The Entity Type dialog box opens (Figure 32-5). You can build an enumeration by selecting options from the enumeration field lists or you can type in the enumeration directly.
For each field of the simulation object type (Kind, Domain, Country, and so on), select an option from the list.
The options are drawn from the SISO Enumerations document. As you select an option, the enumeration at the bottom of the dialog box changes to reflect your choice. You do not have to make a selection for each field. VR-Forces uses wild carding to match simulation objects against the final enumeration.
If appropriate, add additional enumerations for each simulation object type that is valid for the script.
You can restrict a script to specific Behavior Sets. If you do this, the task will not appear on a menu when you select a simulation object whose force does not have the Behavior Set assigned to it.
To specify that a script is available by Behavior Set:
Select the Make Available Based on Behavior Set check box.
Select each Behavior Set for which you want this script to be available.
You must create the Behavior Sets before you can assign scripts to them. All available Behavior Sets are automatically listed in the dialog box window.
Some scripted tasks and sets are available to simulation objects because they are speci- fied in a system that the simulation object uses. They are not assigned to simulation object types as part of the script meta data.
This method is used for many of the system scripted tasks supplied with VR- Forces.
Scripted tasks and sets are specified in a system definition by their script IDs in the script-ids parameter. (In AggregateLevel.sms, some scripted tasks for combat engineering objects are specified in the create-script-id, improve-script-id, and destroy-script-id parame- ters.) Script IDs can be specified in a script-enable-controller and in controllers derived from it.
The following example is from ground-aggregate-movement.sysdef in AggregateLevel.sms. Any simulation object with this system definition can use the Maximum_Speed_Modi- fier, Halt_Movement, Move_To_Location_Plan_Path, and Move_To_Way- point_Plan_Path scripted tasks. The variables described in the script-variables block are accessible to the script through the vrf:getScriptAttribute() function.
(script-enable-controller
(component-descriptor-type "script-enable-controller-descriptor")
...
(script-ids "Maximum_Speed_Modifier" "Halt_Movement" "Move_To_Location_Plan_Path" "Move_To_Waypoint_Plan_Path")
(script-variables
(maximum-speed-modifier-variables (script-id "Maximum_Speed_Modifier") (variables
(DtRwReal Rain-Modifier-By-Intensity
$rain-modifier-by-intensity) (DtRwReal Snow-Modifier-By-Intensity
$snow-modifier-by-intensity) (DtRwReal Visibility-Degrades-When-Below
$visibility-degrades-when-below) (DtRwReal Visibility-Can-Degrade-Speed-Up-To
$visibility-can-degrade-speed-up-to)
)
)
(move-to-location-variables
(script-id "Move_To_Location_Plan_Path") (variables
(DtRwString Obstacle-Feature-Query "MAK_OBSTACLE") (DtRwString Path-Feature-Query "MAK_ROAD")
)
)
...
)
)
The following example is from the aggregate-5-inch-gun.sysdef in AggregateLevel.sms. It adds the script-ids parameter to the unit-indirect-fire-controller, which is derived from the script-enable-controller. Any simulation object with this system can use the Indirect Fire and Limited Munition Attack scripted tasks.
(weapon-indirect-fire (systems ) (sensors ) (controllers
(aggregate-indirect-fire-controller
(component-descriptor-type "aggregate-indirect-fire-controller- descriptor")
(component-type "aggregate-indirect-fire-controller") (min-tick-period -1.000000)
(min-tick-period-variance -1.000000)
(process-state-repository-name "aggregate-indirect-fire- controller-process-state-repository-default")
(process-state-repository-type "aggregate-indirect-fire- controller-process-state-repository")
(is-enabled True)
(script-ids "Indirect_Fire" "Limited_Munition_Attack") (weapon-name "5 inch shell")
...
)
)
The following example is from obstacle-builder.sysdef and shows the create-script-id and
improve-script-id parameters:
(creatable-objects (affectable-object
(object-type 1 (16 1 0 62 3 0 0))
(time-to-complete $time-to-create-abatis) (range $creation-range-abatis)
(create-script-id "Construct_Abatis") (improve-script-id "Improve_Obstacle")
)
...
)
There may be occasions when you want to have tasks or sets with the same name that work differently depending on the simulation object you give them to. For example you might have a movement task that works one way for an individual entity and another way for a unit. You can ensure that when you select a simulation object it gets the correct version of the script by specifying the simulation object type that the script is available to. To simplify the Task or Set toolbars, you can map these different scripts to the same toolbar button. This is done by specifying that one script is equivalent to another script.
If you map multiple scripts to the same toolbar button, when you select a simulation object, the toolbar button is enabled and you can give the simulation object the task or set. VR-Forces chooses the correct version of the script. If you select multiple simula- tion objects that would have different versions of the script, the toolbar button becomes disabled.
To specify an equivalent script for a Task or Set Toolbar button:
Create a new script.
On the New Script dialog box (or Edit Script dialog box), select Show Task on Task Toolbar (or Show Set on Set Toolbar).
Click the Toolbar Location edit button 
). The Select Location on Task (Set) Toolbar dialog box opens.
Select the task or set that you want this script to be equivalent to. The Equivalent To button becomes active.
Click the Equivalent To button. Text is added to the script’s entry in the list indi- cating the script it is equivalent to (Figure 32-6).
Figure 32-6. Select Location on Task Toolbar dialog box
Do not move the new script to a different location on the toolbar. Moving it breaks the equivalency. Users will click the equivalent task or set’s button to access this it
Click OK.
Save the script.
The Language option only applies to Task and Set type scripted tasks. Reactive tasks and background processes are always written in Lua.
If a developer adds a new C++ task controller using this approach, it looks for the script ID of the scripted task. For example, the Deploy and Recover tasks for embedded enti- ties use the scripted task interface to create their dialog boxes. The addTask example in the VR-Forces Toolkit demonstrates this method of adding tasks. For more informa- tion, please see VR-Forces Developers Guide.
You can display C++ tasks and sets in the Scripts dialog box by selecting the Show C++ Tasks check box (Figure 32-7).
To create a scripted set:
Choose Simulation Scripts. The Scripts dialog box opens (Figure 32-1).
If you have a folder hierarchy and want to create the script in a particular folder, select the folder. (For more information, please see “Organizing Scripts into Folders,” on page 32-31.)
Choose Script New Script. The New Script dialog box opens (Figure 32-2).
In the Script Type list, select Set. The New Script dialog box redisplays to show the metadata fields for a scripted set (Figure 32-9).
Figure 32-8. New Script dialog box, scripted set
Complete the fields in the dialog box. Fields that are common to all scripts are described in Table 32-1.
The process for creating a reactive task is largely the same as for creating other scripts. This procedure focuses on the differences.
To create a reactive task:
Choose Simulation Scripts. The Scripts dialog box opens (Figure 32-1).
If you have a folder hierarchy and want to create the script in a particular folder, select the folder. (For more information, please see “Organizing Scripts into Folders,” on page 32-31.)
Choose Script New Script. The New Script dialog box opens (Figure 32-2).
In the Script Type list, select Reactive Task. The New Script dialog box redisplays to show the metadata fields for a reactive task (Figure 32-9).
Complete the fields in the dialog box. Fields that are common to all scripts are described in Table 32-1.
To make this reactive task enabled by default, select the Enabled By Default check box.
In the Default Priority box, type the priority for this task. The lower the number, the higher the priority. To help you set the priority, you can view a list of all reactive tasks that are valid for the simulation object types of this task so that you can consider their relative importance and set an appropriate priority.
Optionally, click Compare Priorities to see a list of reactive tasks and their priori- ties.
Click Add.
The procedure for creating a background process is essentially the same as for other script types. The main difference is that there are fewer fields to complete in the New Script dialog box. For details about writing a background process script, please see “Background Processes,” on page 33-30.
To create a background process:
Choose Simulation Scripts. The Scripts dialog box opens (Figure 32-1).
If you have a folder hierarchy and want to create the script in a particular folder, select the folder. (For more information, please see “Organizing Scripts into Folders,” on page 32-31.)
Choose Script New Script. The New Script dialog box opens (Figure 32-2).
Complete the fields in the dialog box. Fields that are common to all scripts are described in Table 32-1.
Figure 32-10. New Script dialog box, background process
Click Add.
Creating Scripted Tasks and Sets — Saving Scripts
When you create or edit a script, its listing in the Scripts window is in italics, prefaced by an asterisk. When you save the scenario, or promote a script to a system script, the script gets saved and the italics and asterisk get removed.
It is likely that you will test scripts by running a scenario and you will want to edit the script as you find problems. If you create or edit a script while a scenario is running and you decide to rewind the scenario without saving it (which would be normal behavior for rewinding a scenario), you are prompted to preserve the changes to the script after the scenario rewinds. The script is still not saved and you will, therefore, receive the standard “scenario modified” prompt when you start the scenario again. You do not have to save the scenario if the only thing that changed is the script. You can continue to run the scenario and rewind while you are working on the script. Eventually you will have to save the scenario if you want to save your changes to the script.
To save a scenario script, save the scenario.
To save a system script, after updating the script in the Edit Script dialog box, click Update.
You can edit scripts.
!
!
If you edit a system script, the changes affect all scenarios that use the script. You are responsible for ensuring that any changes have the intended results for all scenarios that are affected.
To edit the metadata for a scenario script:
Choose Simulation Scripts. The Scripts window opens (Figure 32-1).
Select the script that you want to edit.
In the Script ID column the icon indicates the type of script, Task 
), Reactive Task 
), Set 
), or Background Process 
).
Choose Script Edit Script Meta Data, or double-click the script name. The Edit Script dialog box opens. (If you are editing a system script, you are prompted to confirm that you want to edit it.)
Edit the metadata as desired.
Click Update.
Creating Scripted Tasks and Sets — Organizing Scripts into Folders
You can filter the tasks listed in the Scripts dialog box by selecting options from the lists below the menu bar, as follows:
Script Access: Show system scripts, scenario scripts, or all scripts.
Script Type: Show scripted tasks, reactive tasks, sets, background processes, or all scripts.
Entity Type: Show scripts that apply to the selected simulation object type.
This filter is based on the Valid for Entity Types list for each script. Some scripts do not have any simulation object types listed. These scripts, such as Drop Naval Depth Charge, become available to simulation objects based on the systems that they have configured. Therefore, this list may be somewhat misleading in terms of the overall applicability of scripts to the different platforms.
Show C++ Tasks: Toggles the display of tasks and sets that are written in C++, but whose GUIs are created using the script mechanism.
You can create folders and organize scripts by folder.
To add a folder:
Choose Simulation Scripts. The Scripts window opens (Figure 32-1).
Choose Folders Add Folder. The Folder Name dialog box opens.
Type a name for the folder.
Click OK.
To rename a folder:
Choose Simulation Scripts. The Scripts window opens (Figure 32-1).
Select the folder that you want to rename.
Choose Folders Rename Folder. The Folder Name dialog box opens.
Type a new name for the folder.
Click OK.
Creating Scripted Tasks and Sets — Exporting and Importing Scripts
You cannot delete a folder that has scripts in it.
To delete a folder:
Choose Simulation Scripts. The Scripts window opens (Figure 32-1).
Select the folder that you want to delete.
Choose Folders Delete Folder.
To add a script to a folder, drag it onto the folder.
To remove a script from a folder, drag it away from the folder.
Scenario scripts are saved in a scenario’s SPT file, not as individual scripts. If you want to make a scenario script available to other scenarios, but you do not want to save it as a system script, you can export the script from the scenario in which you created it and import it into any other scenario. You can export multiple scripts to one file as a script “package”.
You cannot add or remove scripts from a script package. To change the contents you would have to create a new package.
If scripts are organized in folders, when you save them the folder structure is also saved.
To export scripts:
Choose Simulation Scripts. The Scripts window opens (Figure 32-1).
Select the scripts that you want to export. (The window supports typical methods for selecting multiple entries in a list.)
Choose Script Export Script Package. The Choose Script File dialog box opens. By default it opens in ./userData/taskScripts.
Type a name for the scripts file.
Click Save. The scripts gets saved to a file with the extension .spt. The file contains the metadata and the script code.
Creating Scripted Tasks and Sets — Exporting and Importing Scripts
If you import a script package that has multiple scripts, you can choose which scripts to import. Scripts get imported with the folder hierarchy that they were saved in.
To import scenario scripts:
Choose Simulation Scripts. The Scripts window opens (Figure 32-1).
Choose Script Import Script Package or click Import Scripts. The Choose Script File dialog box opens.
Select the script file that you want to import.
Click Open. The Import dialog box opens (Figure 32-11). It lists the scripts saved in the script file.
Select the scripts that you want to import.
Click Import.
Creating Scripted Tasks and Sets — Copying a Script
To copy a script:
Choose Simulation Scripts. The Scripts window opens (Figure 32-1).
Select the script that you want to copy.
Choose Script Duplicate. The New Script dialog box opens. If you copied a scenario script, the duplicate script is assigned a new script ID. If you copied a system script, the script ID is not changed. You will have to change the script ID manually.
If you do not change the script ID for a copied system script, the system script gets removed from the list of scripts for this scenario and the new script is added as a scenario script. This lets you experiment with changes to a system script without actually changing it. The original system script will still be available to other scenarios.
Edit the script.
Click Duplicate. The script is added to the list.
To delete a script:
Choose Simulation Scripts. The Scripts window opens (Figure 32-1).
Select the script that you want to delete.
Choose Script Delete Script.
Creating Scripted Tasks and Sets — Creating a System Script
To create a system script, you create a scenario script and then save it as a system script. System scripts are saved in ./data/simulationModelSets/<model_set>/scripts. A system script has two files. The metadata is saved in a file ending with the extension .xml. The code is saved in a file with the extension .lua.
To save a scenario script as a system script:
Choose Simulation Scripts. The Scripts window opens (Figure 32-1).
Select the script that you want to save as a system script.
Choose Script Promote to System Script. You are prompted to confirm the change.
Click Yes.
Most of the system scripted tasks and sets included with VR-Forces are listed on the Task and Set menus. The scripts in the Examples folder and a few others are not listed. You can specify whether or not particular scripted tasks or sets are listed. You might want to do this to reduce clutter on the menus. Or you might want to limit the tasks available to players in a particular deployment of VR-Forces.
A system script’s inclusion on a menu is controlled by the following settings:
The Show Task on Task Menu (or Show Set on Set Menu) check box on the New Script and Edit Script dialog boxes.
The check box next to the script’s entry on the Scripts dialog box (Figure 32-12).
Its membership in a behavior set. The effect of behavior sets on script availability is additive to the configuration discussed in this section. For details about using behavior sets, please see “Using Behavior Sets to Manage Scripts,” on page 26-19.
Creating Scripted Tasks and Sets — Creating a System Script
Figure 32-12. Show script on menu check box
Table 32-3 shows when a scripted task is listed on a menu based on the configuration check boxes selected.
Table 32-3: System scripted task inclusion on Task menu
Show Script on Menu check box
System script list check box
Task included on menu
Yes No
Yes, for this scenario. No
To specify the availability of a system script on a menu:
Choose Simulation Scripts. The Scripts window opens (Figure 32-1).
In the list of system scripts, select the script whose availability you want to change. Use Table 32-3 to determine which check box configuration you need for your desired menu status.
Choose Script Edit Script Meta Data. The System Script Editing prompt opens. (If you have disabled this prompt, the Edit Script dialog box opens. Skip to step 5.)
In the System Script Editing prompt, click Yes. The Edit Script dialog box opens.
Select or clear the Show Task on Task Menu check box (or the equivalent for sets).
Click Update.
Creating Scripted Tasks and Sets — Specifying a Script Editor
In the list of scripts, select the check box next to the system script you are editing to make it available. Clear the check box to make it unavailable.
To specify the editor to use for scripts:
Choose Settings Application. The Application Settings dialog box opens.
Select the Script Options page (Figure 32-13).
Click the Browse button 
) next to the Script Editor box. The Choose Script Editor dialog box opens.
Select the application that you want to use as the editor.
Click Open.
Creating Scripted Tasks and Sets — Editing Lua Files
To edit the code for scenario scripts you need to work through the Script GUI because the scripts are embedded in the scenario scripts file rather than being saved as individual Lua files. System scripts are saved as Lua files, but even in this case it is better to edit them in the context of the entire script process rather than by editing the Lua file.
However, VR-Forces includes some libraries of Lua functions that are independent of any of the scripts. They are available to be included in your scripts. If you want to edit the functions in these libraries or add to them, you need to edit the individual Lua files. The function libraries are in ./userData/scripts. You can open them in any editor, or access them through the Scripts dialog box.
To edit a Lua file from the Scripts window:
Choose Simulation Scripts. The Scripts window opens (Figure 32-1).
Choose Script Edit External Script. A file chooser dialog box opens.
Select the script that you want to edit. The file opens in a text editor.
Edit the file.
Save the file.
This chapter explains how to write Lua scripts for scripted tasks and sets.
The VR-Forces Lua Interface 33-3
Script Loading and Execution 33-6
The Script Execution Sequence 33-9
Limitations for Checkpointing Scripts 33-12
Editing Scripts While a Scenario is Running 33-14
Monitoring the Status of Tasks and Subtasks 33-16
Coding Messages for Translation 33-21
Create and Move to Waypoint Metadata 33-24
The Create and Move to Waypoint Lua Script 33-26
Writing Scripts
The classes and functions in the Lua interface are documented in the VR-Forces Lua API Documentation. This is a set of HTML files similar to the VR-Forces Toolkit documentation. It is accessible from the Windows Start menu or in
./doc/luadoc/index.html.
The Lua interface defines classes for common objects and functions. The classes in the interface are not fully featured classes as in the C++ language, but they do abstract the representation of information associated with an object and collect a set of methods related to the object. In Lua, to call a method fn on object obj, write:
obj:fn()
Several of the classes defined in the interface do not have constructors, because their objects are pre-defined or created only as return values to other functions. The classes and pre-defined objects in the interface are as follows:
ComponentSystem. A component system is a capability that is assigned to a simula- tion object in the Simulation Object Editor. Systems represent movement and damage capabilities, and represent individual weapons and sensors. In scripts, system objects are obtained from the ownship simulation object (“this”) with a call to getSystem(), passing the name of the system (as used in the Entity Editor) as an argument. The script can then access various attributes of the system through getAttribute calls.
FeatureSet. This class represents a set of features obtained from a query to the terrain database. A FeatureSet is created with a vrf query function. FeatureSet methods allow a script to examine the features to determine their attribute values, vertex locations, and so on.
Location3D, Vector3D, VectorGeoc3D, VectorOffset3D. These classes represent geometric objects. For more information, please see “Geometry,” on page 33-18.
ScriptAnimationModel. ScriptAnimationModel refers to an animation model that can be used by a scripted task to animate an entity's movement. This class is serial- ized to the simulation and might contain movement data if supplied by the devel- oper.
SensorGimbal. SensorGimbal is a class of Lua object that represents a sensor that rotates on a gimbal.
SimObject. SimObject refers to a single object in the simulation. It may be an entity, waypoint, route, or any other simulation object. These objects may be VR-Forces simulated objects, or remote objects received over DIS or HLA by VR-Forces.
SwingingArtPart. SwingingArtPart is a class of Lua object that represents a rotating
Writing Scripts — The VR-Forces Lua Interface
articulated part.
TranslatableArtPart. TranslatableArtPart is a class of Lua object that represents a translating articulated part.
TranslatableStream. TranslatableStream is a text stream class that can be translated by VR-Forces for display in the GUI as text that is translated to the current language the user is displaying (as long as those translations exist.)
SimObject. SimObject is a class that represents simulation objects in VR-Forces. There is no constructor for SimObjects in the interface, but there are vrf functions that create objects, that get objects by name, that get nearby objects, and so on. SimObject methods are provided for getting information about the object such as location, force type, and embarkation status.
this. this is an object of class SimObject that is defined for all Lua scripts. It represents the simulation object running the script, also known as “ownship”. It is not possible to construct a this object in a script. In addition to being able to use all of the SimObject methods, a Lua script can change the location and heading of this, manipulate its resources, and examine the contacts detected by the simulation object’s sensors.
vrf. vrf is defined as a global object for all Lua scripts. It is an instance of a class that represents the Lua interface; other instances cannot be created in a script. The vrf object provides functions that control and access information in the VR-Forces simulation.
In Lua, variables assigned to objects actually just hold a reference to an object, so that if one variable is assigned to another they will both hold a reference to the same object. In the following example, firstObj and secondObj refer to the same object.
firstObj = getObjectByName("APC 1") secondObj = firstObj
In most cases this is what a Lua programmer wants. However, for the geometric objects, a Lua programmer may sometimes want to make a copy of an object. A simple assignment does not make a copy in Lua, so the geometric objects have makeCopy() methods to provide copies.
Table 33-1 lists reserved words (in addition to those reserved by Lua), which should not be used except for their intended purpose.
Name | Module | Function |
vrf | vrf | Module singleton |
this | SimObject | Ownship name |
ScriptVrfObject | SimObject | Class name |
Location3D | Location3D | Class name |
Vector3D | Vector3D | Class name |
VectorGeoc3D | VectorGeoc3D | Class name |
VectorOffset3D | VectorOffset3D | Class name |
ScriptFeatureSet | FeatureSet | Class name |
ScriptAnimationModel | ScriptAnimationModel | Global function |
vrfprint | vrfutil | Global function |
printDebug | vrfutil | Global function |
printVerbose | vrfutil | Global function |
printInfo | vrfutil | Global function |
printWarn | vrfutil | Global function |
printError | vrfutil | Global function |
EntityType | vrfutil | Global table of functions |
bhaveLoaded | vrfutil | Global function |
new | fsm | Function name |
The Lua interface includes Lua modules for use in Lua scripts. A module stuff can be accessed in a Lua script by writing
require "stuff"
The modules available in the interface are as follows:
vrfutil. Technically, vrfutil is not a Lua module. (It is not defined with a module function.) It is just a set of global utility functions. The Lua script template that opens when a new script is created contains:
require "vrfutil"
so that these functions are available to the script by default.
fsm. The fsm module defines a class that implements finite state machine logic. There is one function in this module, new(), which creates an fsm object.
exectool. The exectool module is a package of functions that supports the use of a single Lua function to describe the control flow of a scripted task. To use this tool, the task logic is described in a function we call a scriptFunction. This function is written as if it will execute up to a subtask invocation, and then wait until that subtask is completed before continuing.
The .lua module files are located in ./userData/scripts. You can add user-created modules to this directory and then import them into scripts with a require statement.
This section describes script entry point functions and the execution sequence for scripted tasks and sets. It also describes how VR-Forces checkpoints scripted tasks and executes them when a checkpointed scenario is run.
The Lua API includes functions that we call “entry points” to a scripted task. When you create a new script, they are included in the default script template. Unlike the Lua functions that you might write as part of a script, you do not have to call entry point functions from within the script. They are called by the simulation engine. (However, if an entry point function is not defined in a script, it does not get called.)
init(). Use init() to set up the initial state of your scripted task’s environment. The init() function is the first function called when a scripted task is executed. It is called when a task is assigned to a simulation object, even if the scenario is paused. It is never called again for the life of the scripted task.
tick(). The tick() function is the heart of every scripted task. It is called at every tick of the simulation engine once the simulation object has completed its initialization. Most of a scripted task's logic should be written into the tick() function as it is the only entry point function consistently called in the script.
suspend(). The suspend() function gets executed when a reactive task is triggered for a simulation object and the reactive task cannot run concurrently with the current task. The typical behavior, as embodied in the scripted task template, is to stop all tasks and subtasks.
resume(). The resume() function gets executed when a reactive task completes. The typical behavior is to reinitialize the suspended task.
As you can see from their descriptions, the suspend() and resume() functions do not exactly suspend and resume tasks as those terms are commonly understood. In most cases (this is task dependent), VR-Forces does not preserve the state of a simulation object’s tasks when they are suspended, it stops the tasks. Nor does it resume the previous task from the point at which it was suspended, it restarts the task from the current state of the simulation object. However, VR-Forces always saves the lua state of scripted tasks, so when a scripted task resumes, its variables may need to be reset in init() or checkInit().
saveState(). If a script is running, the saveState() function is called just before a scenario is about to be saved. VR-Forces automatically saves the state of script execution. (For details, please see “Limitations for Checkpointing Scripts,” on page 33-12.) This function lets you do any additional processing to save the state of your scripted task. Most scripts do not use this function.
loadState(). If a script was running when a scenario was saved, the loadState() func- tion is called just after a scenario is loaded or rewound. VR-Forces automatically restores the state of a scripted task that was running when a scenario was saved. This function lets you do any additional processing required to restore the state of the script. If your script uses the saveState() function, you probably want to include complementary processing in loadState(). Most scripts do not use this function.
If your loadState() function assumes the presence of other simulation objects, you must take into account that other simulation objects might not have loaded yet when the function is called.
shutdown(). The shutdown() function is called when the task is ending for any reason. You will not typically need to write any code in this function, however it is available if there is a case in which you want to do anything before the task ends.
receiveTextMessage(). The receiveTextMessage() function is called when the simu- lation object executing this task receives a text message. The function provides some data to determine what the text message is and which simulation object the text message came from. This function takes two arguments, the message and the sender. The message is a text string and the sender is the simObject that sent the message.
The following script entry points are only used in reactive tasks:
check(). The check() function defines the condition under which the reactive task gets triggered. It keeps checking the condition until it becomes true, at which point it starts the reactive task.
checkInit(). The checkInit() function initializes the reactive task when it is enabled. It sets the initial conditions for the check() function. checkInit() runs when a reac- tive task is first enabled and runs again after the reactive task completes so that it can begin checking the condition again.
A Lua script has several distinct sections, including the entry points described in “Script Entry Points,” on page 33-7 and the global commands in the script. When a scripted task is assigned to a simulation object, the following actions happen, even if the scenario is paused:
The script environment is initialized. This step defines the vrf and this objects and all of the class functions in the Lua API.
The script text is loaded. All Lua statements in the global scope are executed. Normally, the script defines (assigns initial values to) global variables here.
The init() function is called.
This sequence is followed whenever a scripted task is assigned, including the following situations:
A scripted task is assigned while the scenario is running.
A simulation object has a script assigned at the beginning of a scenario and the scenario is loaded or rewound.
You modify the script or script metadata while the script is running.
If the simulation is running, after the init() function is called VR-Forces begins calling the tick() function at the period specified by the setTickPeriod() function (default: 0.5 seconds).
Suppose a script “test” contains the following code:
print("Global statements") t = {}
function init() print("Init function") vrf:setTickPeriod(0.5) t[1] = 0
end
function tick()
table.insert(t, vrf:getExerciseTime()) print("Tick ", #t)
end
If the script is assigned to a simulation object and then the scenario runs for a short time, the console output would be as follows:
Global statements Init function
DtCgfDispatcher::controlScenario: run Tick 2
Tick 3
Tick 4 DtCgfDispatcher::controlScenario: pause
Figure 33-1 illustrates the control flow for a scripted task.
Assign task
Assign task
Global scope
Global scope
init()
init()
tick()
tick()
Is task
complete? No
Yes
shutdown()
shutdown()
Figure 33-1. Scripted task control flow
Figure 33-2 illustrates the script execution sequence for reactive tasks. It is distinguished from that for scripted tasks by the addition of the checking process.
Enable task
Enable task
Global scope
Global scope
checkInit()
checkInit()
check()
check()
Is check
true? No
Yes
init()
init()
Run task
tick()
tick()
Is task
complete? No
Yes
Figure 33-2. Reactive task control flow
When a scenario is saved (checkpointed), VR-Forces first runs saveState() and then saves the Lua state in the scenario file. (Checkpointing a scripted task has some limita- tions. For details, please see “Limitations for Checkpointing Scripts,” on page 33-12. For general details about checkpointing, please see “Saving a Scenario,” on page 7-27.) When a saved scenario is loaded, the following steps are taken to restore the scripted task:
The script environment is initialized. This step defines the vrf and this objects and all of the class functions in the Lua API.
The script text is loaded. All Lua statements in the global scope are executed. Global variables defined and initialized in this part of the script are re-initialized.
VR-Forces restores the values of global variables to the saved values. These values replace the initial values assigned in step 2.
The loadState() function is called.
i The init() function is not run when a scenario is reloaded.
Assume that the “test” scripted task described in the previous section is saved at the point shown in the sample code (t = 4). When the scenario is run from the checkpoint, the console output will be as follows:
DtCgfDispatcher::controlScenario: run Tick 5
Tick 6 DtCgfDispatcher::controlScenario: pause
When VR-Forces saves (or checkpoints) a scenario, it saves the following aspects of the Lua state in the checkpoint:
The values of global variables that contain strings, numbers, and objects (of the classes listed in “Lua Classes,” on page 33-3).
Tables, but only table values that contain strings, numbers, objects, and tables. Tables cannot contain values that refer to the same table, either directly or indi- rectly through another table.
The following aspects of the Lua state do not get saved in a checkpoint:
Variables containing functions or threads.
Variables declared in the global scope with the keyword local preceding the declaration.
Table entries that do not use numbers or strings as keys.
Lua scripts that contain elements that do not get saved can still be restored after a checkpoint if the global statements in the script reset the elements. For example, a vari- able containing a function is not saved in the scenario file, but if this variable is initial- ized in the global Lua statements, it is reset when those statements are loaded. However, if the value of this variable was changed during script execution (in the init() or tick() functions), then its value will not be restored correctly.
Tables that reference themselves in the table do not get saved properly. To demonstrate how scripted tasks get saved, assume the following script:
print("Global statements") a = 0
t = {foo = 0, bar = 1}
f = function () print("hello") end function init()
print("Init function") vrf:setTickPeriod(0.5) a = 100 -- change a
t.foo= 10 -- change t.foo t.bar = nil -- remove t.bar
f = function () print("world") end -- change f end
function tick()
print ("Tick. a = ",a, "t.foo = ", t.foo, "t.bar = ", t.bar) f()
print() end
The output the first time the scripted task runs is as follows:
Global statements Init function
DtCgfDispatcher::controlScenario: run
Tick. a = 100 t.foo = 10 t.bar = nil world
When the scenario is saved and then reloaded, and the simulation is run again, the following is printed:
DtCgfDispatcher::controlScenario: run
Tick. a = 100 t.foo = 10 t.bar = 1 hello
A comparison of the outputs reveals that variable a and table entry t.foo were restored to the correct values. However, table entry t.bar and function f were re- initialized in the global statements, but were not restored to the values they had when the scenario was saved.
Global variables get saved when a scenario gets checkpointed in one of the following ways:
If the checkpoint mode is AllGlobals, all global variables defined are saved.
If the checkpoint mode is CheckpointStateOnly, the script only saves variables that are part of the checkpointState table. If you remove this value, it defaults to the behavior of saving all globals.
vrf:setCheckpointMode(CheckpointStateOnly)
The following code, from vrfutil.lua, defines some global values:
-- Global booleans to help define which checkpoint state to use AllGlobals = false
CheckpointStateOnly = true
For more information about vrf:setCheckpointMode, please see the VR-Forces Lua documentation.
You can add, remove, and edit scripts during scenario creation or while a scenario is running. If a script is not being used by any simulation objects, editing or deleting it has no effect on the scenario. If you change a script that is being executed by a simula- tion object, when you save the change the script may be stopped, restarted, or continue to execute depending on what has changed.
Table 33-2 lists the effect on scripts and scripted tasks running as subtasks if you edit the code or metadata:
Table 33-2: Side effects of editing scripts
Change to script Result
Change to script Result
Change code or any metadata except the script ID. Entity type is still supported.
The script restarts. Changes to the Action Cate- gory take effect when the scenario restarts.
Entity types supported changes. The script stops for simulation objects that no
longer support it.
Script ID changes. The script continues to execute. Any script that uses this scripted task as a subtask will fail until its code is updated to use the new script ID.
If you changed the simulation object types that can use the script, then it is added to or removed from the menu for the appropriate simulation object types. (This change takes place immediately.)
The primary way that a scripted task carries out actions is through starting subtasks for the simulation object running it or sending tasks to other simulation objects. All C++ tasks and other scripted tasks are available for sending as subtasks or tasks.
If a scripted task needs to give a task to the simulation object that is running it, it does so as a subtask. (The simulation object’s current task is the scripted task itself, so any action that it needs to take is a subtask to the scripted task.) Subtasks are started using the vrf:startSubtask() function.
If a scripted task needs to give a task to a simulation object other than the one running it, it uses the vrf:sendTask() function.
A startSubtask() or sendTask() function specifies the task name and task parameters, if any. The name must be the name of one of the C++ tasks, as listed in the Task page of the Lua API Documentation, or the script ID of another scripted task.
The task parameters are passed as a Lua table, with parameter names as the indices and the parameter values as the values. The valid parameters for C++ tasks are listed in the Lua API documentation. For scripted tasks, the parameter names are the parameter names defined for that task. You can view them by opening a scripted task in the Edit Script dialog box. Any parameters that are not specified when starting the task use their default values.
The following example subtask gives a Move to Waypoint task to the simulation object running the scripted task:
vrf:startSubtask("move-to", {destination = "Waypoint 1"})
If a task does not have any parameters, startSubtask() must represent the parameters as {}. For example:
vrf:startSubtask("wait", {})
The following example task sends a Patrol Between Waypoints task to the simulation object named “someEntity”:
vrf:sendTask(someEntity, "patrol-two-points",
{first_control_point="Waypoint 1", second_control_point="Waypoint 2"})
If a task is started with an invalid name or invalid parameters, a runtime error will occur in the script.
If a task is started on a simulation object that cannot execute it, the task will enter the Complete (failed) state shortly after the start call is made. This may not happen until a subsequent tick of the scripted task.
Writing Scripts — Tasks and Subtasks
Once a task is started, the scripted task that started it can monitor it using its task ID. A task can be in one of three states: Running, Complete, or Canceled, as follows:
Running. The task was started, but has not completed or been canceled.
Complete (success). The task has completed, and called endTask(true) to end itself.
Complete (failure):
The task has ended itself by calling endTask(false).
The task failed to start because the simulation object was incapable of executing this task.
Canceled:
The task was explicitly canceled using stopTask().
The task was replaced by a conflicting task.
The user issued a Skip Task.
The success or failure of task completion is defined by the task being executed, and may not be consistent between task types.
Subtasks are monitored with the functions:
isSubtaskComplete(taskID)
subtaskResult(taskID)
isSubtaskRunning(taskID)
isSubtaskCanceled(taskID).
Tasks are monitored with the functions:
isTaskComplete(taskID)
taskResult(taskID)
isTaskRunning(taskID)
isTaskCanceled(taskID).
Any task or subtask that has been started from a scripted task can be stopped by that task before it has completed. This is done using stopTask(taskID) or stopSub- task(taskID).
Task parameters are the parameters that are gathered from the user, or set by a parent task, when a task is started. They are passed into the new task when it starts.
For scripted tasks, the task parameters are available in a Lua table named taskParameters available in the global scope. The table contains items named using the parameter names specified in the parameters section of the Scripted Task dialog box when the task was created. The types of these parameters depend on the parameter types selected by the user in this dialog box. Table 33-3 lists the parameter types you can specify when you create a scripted task and the corresponding Lua types in the taskParameters table.
Table 33-3: Task parameters and Lua types
Parameter Type Lua Type
Parameter Type Lua Type
Aggregate Formation String
Altitude MSL Number (meters)
Bomb Resource String (resource name)
Boolean Boolean
Choice (List) Number (Index of the option chosen)
Choice (Option Button) Number (Index of option chosen)
DI-Guy Animation String
DI-Guy Appearance String
Distance Number (meters)
Emitter Number (Index of the emitter system) Simulation Object Type String (DIS type enumeration, colon separated) Force String
Heading Number (radians)
Integer Number
Location (with altitude) Location3D
Location (without altitude) Location3D
Munition Resource String (resource name)
Offset Location VectorOffset3D
Real Number
Resource String (resource name)
Simulation Object (Single) SimObject Simulation Objects (Multiple) Table of SimObjects
Speed Number (meters / second)
String String
Time Number (seconds)
Turn Rate Number (radians / second)
The Lua interface includes classes representing geometric objects. The classes represent locations and vectors in three dimensional space. Different classes are defined for vectors in different contexts so that functions that manipulate them know what their context is and can convert between contexts automatically. Therefore, a script does not have to, for example, create rotation matrices to perform coordinate transformations between vectors that are in an entity-body context and vectors that are in a world context.
A Location3D represents a point in three-dimensional (3D) space. Scripts can access the three components of the location as latitude, longitude, and altitude. There is no other access to components in any other coordinate system. Methods are available to construct a Location3D, to create a vector from the difference between two locations, and to generate a new point by adding a vector to a location.
A Vector3D is a direction in a north-east-down coordinate system. Scripts can access these three components of a Vector3D, or access bearing-inclination-range (Figure 33-4). This is the type of vector that scripts will use most often to find directions between locations, to create new locations relative to other locations, and so on.
North
North
Range
Range
Bearing
Inclination
Down
East
Figure 33-3. Vector3D: North-East-Down, or Bearing-Inclination-Range
When viewed from the perspective of a 3D Cartesian coordinate system that is fixed to the earth, there is no single north-east-down coordinate system. This is because “north” and “east” directions vary depending on where the observer is located on the earth. The Vector3D is therefore similar to a vector in topographic coordinates. At higher latitudes, “north” for two different simulation objects may not be the same direction (for example, two planes near the north pole, but at different longitudes, that are both flying “north,” are not on parallel courses).
Writing Scripts — Geometry
Figure 33-3 shows two north-east-down coordinate systems with origins at different locations on the earth. The coordinate systems have different orientations with respect to a coordinate system fixed to the earth.
North
East
Down
North
Down East
Figure 33-4. Coordinate systems with different origins
A Vector3D is not strictly a vector, in that it is not a straight line in a Cartesian coordi- nate system fixed to the earth. Just as the direction “east” changes (viewed in the Carte- sian coordinate system) to follow the curvature of the earth, so does a Vector3D. This definition is different from topographic coordinates, which are Cartesian coordinates fixed to a point on the surface of the earth. Implications of this definition include the following:
The heading of a Vector3D from one location to another is the heading of the shortest route around the earth (the great circle route) between the locations. The length is the great circle distance.
The inclination of a Vector3D between two locations with the same altitude is 0.0, even when one location is over the horizon from the other.
A Vector3D with length equal to the circumference of the earth, and inclination 0.0, when added to a location on the surface of the earth will produce a location coincident with the first location.
A VectorOffset3D is a set of three values that define an offset from some reference direc- tion defined by a Vector3D. The three values represent right-forward-up, where:
forward is in the same direction as the reference.
right is to the right in a horizontal plane. Horizontal means the plane defined by an inclination of zero; this definition implies that the “roll” component of the refer- ence direction is assumed to be zero.
up is perpendicular to forward and right, that is, right X forward.
A VectorOffset3D is appropriate to use, for example, to define the offsets of simulation object formation positions from a central location. Actual formation positions could be generated by transforming the offsets to Vector3Ds using the direction vector of the simulation object, and then adding the Vector3Ds to the simulation object location.
A VectorGeoc3D is a vector in a Cartesian coordinate system fixed to the earth (geocen- tric coordinates). The actual coordinate meanings and values are not accessible to the script, because they are considered to be abstract. A VectorGeoc3D can be generated only by taking the difference of two locations, or by transforming a Vector3D at a particular location.
A VectorGeoc3D between two locations is the line-of-sight vector between the locations. Therefore:
A VectorGeoc3D between two points on opposite sides of the earth, at the same alti- tude, will go through the earth. (A Vector3D, by contrast, will go around the earth parallel to the surface.)
The angle between two VectorGeoc3D vectors corresponding to north for two simu- lation objects near the north pole will be the difference in their longitudes. (The angle between their Vector3Ds for north, by contrast, will be zero.)
The Lua interface does not have any simulation functions that require VectorGeoc3Ds. However, they may be manipulated to compute angles and so forth.
Writing Scripts — Error Detection
VR-Forces has a utility, translationFileCreate, that can extract the user-visible text in a script dialog box and make it available for translation. (For details, please see “Local- izing the Graphical User Interface,” on page 2-10.) If a script contains messages such as printWarn, printInfo, and so on, you can code these messages so that they are also extracted to the translation file.
To code messages for translation, use the following syntax:
printWarn(vrf:trUtf8("Text message."))
You can include variable data in the message, as follows:
printWarn(vrf:trUtf8("Some text %1. Some more text
%2):arg(variable1):arg(variable2))
where an argument can be a string or number.
For more information about coding for translation, please see the !HowToPrint page in the Lua documentation (./doc/luadoc/index.html).
The VR-Forces Lua implementation can detect syntax errors and runtime errors.
When you save a script, it is checked for syntax errors. If an error is found, it is reported in an error message. In Figure 33-5, the if statement in line 7 is missing the then keyword.
Detection of a syntax error does not prevent the script from being saved. If you do not fix the error and try to use the script, the back-end generates an error.
Writing Scripts — Error Detection
When you run a script, the back-end can detect errors due to incorrect use of user func- tions and the Lua API functions, such as calling an object that does not exist, or trying to access feature data before it is paged in. When a runtime error is detected, the back- end generates an error message. When the back-end generates an error, the script that caused the error is displayed in bold, red type in the Scripts dialog box (Figure 33-6). Therefore, you may want to keep the dialog box open while you are testing new or edited scripts.
Figure 33-6. Lua error message
To view an error message:
In the Scripts dialog box, select the script that has generated an error.
Choose Script View Script Error. An error message is displayed.
i Script errors are also sent to the console in the Information dialog box.
You can write scripts that request input from the VR-Forces user. Script questions are sent to the simulation object’s object console and to the Object Console Summary Panel. Users can answer questions from the Object Console Summary Panel.
To create interactivity in a script, use the vrf:askUserQuestion() Lua function. When a script sends a question to the console, the Answer Questions button becomes active.
When the user clicks the button, a set of choices is displayed. The choices can be presented as buttons, as option buttons, or as a drop-down list.
The script can do whatever it wants with the user input.
VR-Forces includes many scripted tasks, all of which can serve as examples of how to write one. The Create and Move to Waypoint scripted task is a basic example that shows you how to:
Set up metadata.
Include the VRF Utilities module.
Initialize a subtask ID.
Use the init() function.
Create a waypoint using input from the task’s dialog box.
Send a set data request to a simulation object, using input from the task’s dialog box.
Use the tick() function.
Send a subtask and get the subtask ID.
Check for completion of the task.
Stop the task.
The Lua code is comprehensively commented. This section supplements the comments.
Figure 33-7 shows the metadata for the Create and Move to Waypoint scripted task.
Figure 33-7. Create and Move to Waypoint script
To view the metadata:
Choose Simulation Scripts. The Scripts dialog box opens.
Expand the Examples folder (Figure 33-8).
Select Create and Move to Waypoint.
Choose Script Edit Script Meta Data. The Edit Script dialog box opens (Figure 33-7).
Note how the Name column of the Create and Move to Waypoint entry in the Scripts dialog box matches the Menu Text in the Edit Script dialog box. The Script ID and Description fields are also drawn from the scripted tasks metadata.
Now let’s look at the parameters. This scripted task has two parameters, waypointLoca- tion and orderedSpeed. To see the definition of a parameter, select it and click the Edit button 
). Figure 33-9 shows the dialog boxes that specify the parameters.
Figure 33-9. Parameter definitions
Figure 33-10 shows the dialog box that is displayed when you assign a simulation object this task. Note that the description of the task on the dialog box matches the descrip- tion in the metadata. The parameter labels in the dialog box match the labels specified for the two parameters. The labels are not the same thing as the parameter name. The parameter name is the name used in the Lua script for this scripted task.
Figure 33-10. Create and Move to Waypoint dialog box
When this scripted task is assigned to a simulation object, the user will specify the waypoint and the ordered speed. Then the scripted task executes. Now we will look at the Lua script to see what happens.
The entire Lua script for this scripted task (without comments) is as follows:
require "vrfutil" moveToWaypointSubtaskId = -1 function init()
vrf:setTickPeriod(0.5)
waypoint = vrf:createWaypoint({location=taskParameters.waypointLocation, force=this:getForceType()})
vrf:sendSetData(this, "set-speed",
{speed=taskParameters.orderedSpeed})
end
function tick()
if moveToWaypointSubtaskId == -1 then moveToWaypointSubtaskId = vrf:startSubtask("move-to",
{control_point=waypoint})
end
if vrf:isSubtaskComplete(moveToWaypointSubtaskId) then vrf:endTask(true)
end end
function shutdown() vrf:deleteObject(waypoint)
end
The comments in the script describe the control flow. The essence is that using the input from the task dialog box, the waypoint gets created and the speed gets set in init(). The first time the task is ticked, it sends the Move to Waypoint subtask. There- after, each time the task is ticked, it checks to see if the subtask is complete. When the subtask is complete, the task is ended and the waypoint is removed.
The functions in this script are all in the vrf class, which is described in “Lua Classes,” on page 33-3. The createWaypoint() function takes its location from the waypointLo- cation parameter that was defined in the scripted task metadata and whose value was provided in the Create and Move to Waypoint dialog box when the task was assigned. Similarly, the ordered speed is set with the sendSetData() function and the value is taken from the orderedSpeed parameter for the task. The script gets the parameter values with the taskParameters.parameter syntax.
This script uses three of the entry point functions – init(), tick(), and shutdown(). If you were to checkpoint the scenario while the script was executing, the standard save actions would take place, but no script-specific actions would be taken, because there is no saveState() function in the script. Similarly, no special action would be taken when the scenario was loaded again because loadState() is not used.
For details about the parameters and return values of the functions, please see the VR- Forces Lua API documentation. Similarly, the tasks and set data requests that you can assign with the startSubtask() and sendSetData() functions are described on the Task and Set pages of the Lua API documentation. You should review the lists of functions to see what you can do in a scripted task.
Writing Scripts — A Simple Scripted Set
This example script shows how to create a scripted set. It takes two input values from a dialog box using setParameters. Then it uses the sendSetData() function to set the values for the entity. It needs an endSet() function to finish the process.
require "vrfutil" function init()
vrf:setTickWhilePaused(true) vrf:setTickPeriod(0.5)
end
function tick()
vrf:sendSetData(this, "set-speed", {speed=setParameters.setSpeed}) vrf:sendSetData(this, "set-force", {force=setParameters.setForce}) vrf:endSet()
end
The following scripted task does exactly the same thing as the scripted set. It sets the speed and force of the selected simulation object. The difference is that since this is a scripted task, it interrupts the task that the simulation object is executing. Try these two scripts to see the difference.
require "vrfutil" function init()
vrf:setTickWhilePaused(true) vrf:setTickPeriod(0.5)
end
function tick()
vrf:sendSetData(this, "set-speed", {speed=taskParameters.setSpeed}) vrf:sendSetData(this, "set-force", {force=taskParameters.setForce}) vrf:endTask()
end
As you can see there is nothing in the scripts that identifies them as a scripted task or scripted set. VR-Forces determines the type of script from the myScriptType value in the metadata. Scripted task types are defined in
./include/vrfutil/scriptedTaskMetaData.h.
Writing Scripts — A Simple Reactive Task
The simple reactive task in this section monitors the speed of a simulation object. When it exceeds 15 meters per second, the simulation object is destroyed. The script works as follows:
The checkInit() function sets the tick rate to 1.0 second.
In check(), VR-Forces gets the speed of the simulation object and prints it to the console.
It tests to see if the speed is greater than 15 meters per second. If the condition is met, the function returns true.
If the function returns true, the script executes init() and begins to tick().
In the tick() function, the simulation object is destroyed and the task is complete. Note that in the executeSetData() function, set-destroy does not have parameters, but the command must include empty braces.
function checkInit() vrf:setTickPeriod(1.0)
end
function check()
currentSpeed = this:getSpeed() print("speed is:", currentSpeed) if currentSpeed > 15 then
return true end
return false end
function init() vrf:setTickPeriod(0.5)
end
function tick()
vrf:executeSetData("set-destroy", {}) vrf:endTask(true)
end
Writing Scripts — Background Processes
Background processes are scripts that run continuously in the background. When you create a background process, you specify which simulation object types it is valid for. Thereafter, whenever you create those simulation object types the background process initializes as soon as the simulation object is created. The supported simulation object type can be as general or as specific as you want it to be, based on the entity type enumeration that you specify.
Background processes are used for simulation object actions that happen continuously in a scenario, such as consuming or receiving supplies, calculating the simulation object’s footprint, and automatically attacking opposing forces.
Background processes have one important restriction - they cannot issue tasks to simu- lation objects or stop their tasks.
There is no indication in the GUI that a background process is running. The only way to know which background processes are available and which simulation objects they might be affecting is to examine them in the Scripts dialog box.
The following code is a very simple background process that checks a simulation object’s speed every five seconds. If the speed exceeds three meters/second, it prints a message to the console. The script’s metadata specifies that it applies to lifeforms.
Therefore, this background process will run for each lifeform entity in the scenario.
require "vrfutil" function init()
vrf:setTickPeriod(5.0) end
function tick()
currentSpeed = this:getSpeed() if currentSpeed > 3 then
print("speed is:", currentSpeed, ". Going too fast.") else
print ("Speed is OK." end
end
34. Setting the State of Simulation Objects
This chapter explains how to set simulation object state, such as speed, force, and target.
Setting Simulation Object State and Attributes 34-4
Ammunition Pacing/Tracking 34-9
Collision Avoidance Types 34-12
Counter Measures Auto Launch 34-13
DI-Guy Characteristics (Appearance, Head, Body Weight) 34-16
Setting the State of Simulation Objects
Equipment Pacing/Tracking 34-20
Food, Water, Fuel, Oil and Lubricant 34-20
Food, Water Fuel, Oil and Lubricant Pacing/Tracking 34-21
Resources Pacing/Tracking 34-35
How Fire-When-Fired-Upon Works 34-37
Sector of Responsibility 34-38
Setting the State of Simulation Objects
Setting the State of Simulation Objects — Setting Simulation Object State and Attributes
The graphical user interface does not necessarily know about the state of a simulation object. When you open a dialog box for a Set command, any data in the dialog box represents either default values or the most recently used value, except for the Altitude, IFF, Location, and Heading dialog boxes, which show the current values for the selected simulation object.
You can check the current status of most simulation object state data in the Information dialog box.
You can filter simulation object selection lists. For details, please see “Filtering the Object Selection Lists,” on page 26-10.
The instructions for setting simulation object state direct you to use options on the Set menu. However, all the options available on the main menu are also available on context-sensitive menus. A limited number of tasks are available on the Sets Toolbar and on the Last Selected Objects Panel.
You can also set the state of tactical graphics. For details, please see Chapter 40, Setting the State of Tactical Graphics.
Setting the State of Simulation Objects — Active Sonar Mode
If an entity has an active sonar system, you can set the sonar mode.
i RPR FOM 1.0 does not support active sonar.
To set the active sonar mode:
Select the entity.
Choose Set Sensors Active Sonar Mode. The Active Sonar Mode dialog box opens.
In the System ID list, select the sonar system that you are setting. The entities provided with VR-Forces just have one active sonar system.
In the Mode list, select a sonar mode or select Off to disable active sonar.
Click OK.
Setting the State of Simulation Objects — Activity
Unknown
Attacking
Bivouacking
Emplacing obstacle
Indirect fire
Jamming
Other
Patrolling
Probing
Retreating.
To specify an activity:
Select the simulation object.
Choose Set Disposition Activity. The Activity dialog box opens.
Select an activity from the list.
Click OK.
Setting the State of Simulation Objects — Aiming
The Aiming set data request tells an entity to aim at a point, an object, or an angle. It does not cause the entity to shoot. If the entity acquires a target, it aims at the target and fires. Then it returns to the aiming behavior specified by the set data request.
An entity can move while it is aiming. If an entity is moving and it can no longer reasonably aim in the specified direction, it stops aiming. For example if the entity is aiming at a point and the entity’s movement causes the point to be behind it, the entity stops aiming (unless it has a turret that can aim in that direction). If the entity stopped aiming while it was moving, when it stops moving, it turns to aim in the specified way.
You can also use this set data request to stop the aiming behavior.
To have an entity aim at a location or object:
Select the entity.
Choose Set Engagement Aiming. The Aiming dialog box opens.
Select the aiming option you want.
Specify the appropriate parameter for the aiming choice:
Aim at Point – specify the location.
Aim at Object – select the object.
Aim at Angle – specify the azimuth and elevation.
Cease Aiming – no parameters required.
Click OK.
Setting the State of Simulation Objects — Altitude
To set an entity’s altitude:
Select the entity.
Choose Set Position Altitude, or click the Altitude button ( ) on the Sets Toolbar. The Altitude dialog box opens. It displays the entity’s current altitude.
Select MSL (mean sea level) or AGL (above ground level) to specify the base for the altitude value.
Type the new altitude.
Click OK.
To set the ammunition level:
Select the simulation object.
Choose Set Disposition Ammunition. The Ammunition dialog box opens.
Select the check box for each type of ammunition that you want to set.
For each selected type of ammunition, adjust the slider or type a value.
Click OK.
Setting the State of Simulation Objects — Ammunition Pacing/Tracking
To specify pacing or tracking for a unit’s ammunition:
Select the simulation object.
Choose Set Disposition Ammunition Pacing/Tracking. The Ammunition Pacing/Tracking dialog box opens.
Select the check box for each type of ammunition for which you want to specify pacing or tracking.
For each selected ammunition type, select an option from the list.
Click OK.
Setting the State of Simulation Objects — Appearance
You can set appearance attributes for simulation objects. The appearance attributes that are available for a simulation object are determined by its entry in
./appData/settings/vrfGui/SISO-REF-010-2010-RC1.xml. The default list of appearance
attributes is based on the DIS standard.
The Lifeform State field of the Appearance dialog box sets the posture for an entity. If VR-Forces does not support a selected posture, it simulates the entity using the closest similar posture. If a posture involves walking or running, VR-Forces chooses the posture to use based on the entity’s speed. For more information about setting posture, please see “Posture (Human),” on page 34-32.
If you want to set the appearance of a human character, use the DI-Guy Appearance set data request, described in (“DI-Guy Characteristics (Appearance, Head, Body Weight),” on page 34-16).
In aggregate-level scenarios, the Appearance set data request is included in the list of commands for the Send Radio Set task and the list of commands available on the Command menu in plans. However, it is not supported and if used, will fail. Its presence is due to the lack of context sensitivity for these menus.
To set appearance values:
Select the simulation object.
Choose Set Appearance Appearance. The Appearance dialog box opens. The settings displayed are the current settings for the simulation object.
Change appearance settings as desired.
Click OK.
Setting the State of Simulation Objects — Capabilities
To arm or disarm an explosive device:
Select the explosive device.
Choose Set Engagement Armed. The Armed dialog box opens.
Select an option from the list.
Click OK.
The capabilities that are available for a simulation object are determined by its entry in
./appData/settings/vrfGui/SISO-REF-010-2010-RC1.xml. The default list of capabilities is based on the DIS standard.
To set simulation object capabilities:
Select the simulation object.
Choose Set Disposition Capabilities. The Capabilities dialog box opens. It displays the current settings for the simulation object.
Change the settings you want to change.
Click OK.
Setting the State of Simulation Objects — Collision Avoidance Types
Collision avoidance settings are saved in an entity’s process state reposi- tory. However, there is no indication in the GUI what these settings are. Therefore, we recommend that you not change collision avoidance settings through the GUI indiscriminately because you may lose track of which entities are avoiding which types of objects. To permanently set collision avoidance for an entity, edit its components in the object parameter database.
When the Collision Avoidance Types dialog box opens, it does not reflect the settings for the selected entities. It only provides a default setting. Make sure that you review all the settings in the dialog box to be sure you do not inadvertently enable or disable a setting that you do not want to change.
The Collision Avoidance Types set data request lets you specify collision avoidance only for broad categories of objects. You can set collision avoidance more specifically in the object parameter database.
To change collision avoidance for specific object types:
Select an entity.
Choose Set Action Collision Avoidance Types. The Collision Avoidance Types dialog box opens.
Select the check boxes for object types to avoid and clear the check boxes for the object types that the entity should not try to avoid.
Click OK.
Setting the State of Simulation Objects — Counter Measures Auto Launch
To set the concealment attribute for a simulation object:
Select the simulation object.
Choose Set Disposition Concealed. The Concealed dialog box opens.
Select an option from the list.
Click OK.
The Contamination set data request lets you set the contamination type for a simula- tion object.
To set contamination:
Select the simulation object.
Choose Set Disposition Contamination. The Contamination dialog box opens.
Select a contamination type from the list.
Click OK.
The Counter Measures Auto Launch set data request lets you enable and disable auto- matic launching of counter measures. If you disable automatic counter measures, you can still launch them manually using the Launch Counter Measures task.
To enable or disable automatic launch of counter measures:
Select the entity.
Choose Set Engagement Counter Measures Auto Launch. The Auto Launch dialog box opens.
Select an option from the list.
Click OK.
Setting the State of Simulation Objects — Current Speed
The Current Speed set data request sets the speed of a simulation object immediately and changes the ordered speed to this new speed value. By contrast, Ordered Speed (“Ordered Speed,” on page 34-29) causes a simulation object to accelerate or decelerate to the desired speed.
A negative value causes the entity to go backwards if it supports backwards movement.
For all simulation objects except humans and fixed-wing aircraft that are in the air, if you set the current speed and the object does not have a task, it begins to move at that speed and then slows down until the speed reaches 0. Fixed-wing aircraft that are in a default orbit mode change their speed to the new current speed. Humans might take a step, but then will stop moving.
To set current speed:
Select the simulation object.
Choose Set Action Current Speed. The Current Speed dialog box opens.
In the Current Speed text box, set the speed.
Click OK.
To set a simulation object’s state to destroyed:
Select the simulation object.
Choose Set Disposition Destroyed. The simulation object is immediately destroyed.
Setting the State of Simulation Objects — Detonation Fuse Type
The Detonation Fuse Type set data request lets you configure detonation of improvised explosive devices (roadside IED entity), suicide bombers, and car bombs. You can set them to detonate immediately, at a certain time delay, or based on the proximity of a target entity. If you specify proximity detonation, you can set the radius of the proxi- mate area. If you specify time, you must set the time in seconds until detonation. Deto- nation Fuse Type implicitly arms the device. (For details about arming devices, please see “Armed,” on page 34-11.)
To configure detonation fuse type:
Select the object that you want to configure.
Choose Set Engagement Detonation Fuse Type. The Detonation Fuse Type dialog box opens.
In the Fuse Type list, select the fuse type (Timed, Immediate, or Proximity).
If you selected a Timed fuse, in the Time box, specify the elapsed time, in seconds, at which the IED should detonate.
If you selected a Proximity fuse, in the Proximity box, specify the radius of the area in which a simulation object will trigger the detonation.
Click OK.
Setting the State of Simulation Objects — DI-Guy Characteristics (Appearance, Head, Body Weight)
The DI-Guy Characteristics set data request determines the clothing and physical char- acteristics of a lifeform when it is displayed in a 3D simulation that uses DI-Guy char- acters.
i The DI-Guy Characteristics set data request applies only to lifeform entities.
To set an entity’s DI-Guy appearance, head, or body weight:
Select the entity.
Choose Set Appearance DI-Guy Characteristics. The DI-Guy Characteristics dialog box opens.
Optionally, in the 3D view only, select the Apply Selected Appearance Immediately check box. This displays the selected entity with the new appearance so that you can see what it looks like before you apply the change.
Optionally, filter the appearance list by choosing options in the various filter lists.
To change the appearance, select an appearance from the DI-Guy Appearance list.
To change the head, select an option in the DI-Guy Head list.
To change the weight of the character, slide the DI-Guy Body Weight slider or change the value in the text box (the range is 0.5 - 5.0).
Click OK.
The DI-Guy Hand Item set data request lets you change the hand item that a character has. DI-Guys can have a variety of hand items. For example, a civilian can have a cell phone, a pistol, or a camcorder, while a soldier can have a variety of weapons.
To set a DI-Guy’s hand item:
Select the entity.
Choose Set Appearance DI-Guy Hand Item. The DI-Guy Hand Item dialog box opens.
Select a hand item from the list.
Optionally, in the 3D view only, select the Apply Selected Hand Item Immediately check box. This displays the selected entity with the new hand item so that you can see what it looks like before you apply the change.
Click OK.
Setting the State of Simulation Objects — Embarked
The Disembarked set data request immediately disembarks a simulation object (as opposed to simulating disembarkation, as done by the Disembark task). It is the equiv- alent of the Objects Disembark command. However, Disembarked allows you to include immediate disembarkation in a plan.
To set a simulation object to be disembarked:
Select the simulation object. (If you are using the 2D icon model, embarked simu- lation objects are not displayed, so you have to select it in the Objects List Panel.)
Choose Set Embarkation Disembarked.
The Embarked set data request immediately embarks a simulation object (as opposed to simulating embarkation, as done by the Embark task). It is the equivalent of the Objects
Embark On command. However, Embarked allows you to include immediate embar- kation in a plan.
The default location for this set data request is the center of the parent simulation object (0,0,0). It does not use preconfigured slots like the Embark task does. If you are using a Stealth observer mode and want placement of embarked simulation objects to look good, you will have to calculate offsets for each simulation object you embark.
!
!
If you are using HLA and want to use the embarkation feature, you must use RPR FOM 2, draft 17 or later.
To set a simulation object to be embarked:
Select the simulation object to be embarked.
Choose Set Embarkation Embarked. The Embarked dialog box opens.
Select the simulation object to embark on.
Optionally, specify a embarkation offset.
Click OK.
Setting the State of Simulation Objects — Emitter
The Emitter set data request enables or disables emitters on simulation objects that have them.
The radar sensor has an emitter component that models basic electromagnetic emis- sions. A simulation object can have multiple emitter components. Each emitter compo- nent can have a list of modes and each mode can have multiple beams.
An emitter component can publish itself as a standard beam type or a tracking beam type. The type is determined by the setting for the targeting-capable parameter in the object parameter database. It applies to all beams emitted by the specific component. If targeting-capable is False, the beam is a standard beam. If targeting-capable is True, it is a tracking beam.
If an emitter component has targeting-capable set to True, it registers for set-target messages. If you set a target for the simulation object on which the emitter is mounted, it publishes the target entity as its tracking target for all of the components beams.
Setting a target does not cause the beam to actually track the target. The beam’s behavior is determined by the parameters in its description in the object parameter database.
The emitter continues to publish the targeted entity as its tracking target until you set another target, regardless of the status of that entity in the exercise. There is no way to set the target to “none”.
Please see “Configuring Emitters,” on page 74-2, for an explanation of how to configure individual and multiple emitters in the object param- eter database.
Please see the online help for the OPD Editor for a description of emitter parameters.
Each emitter has an ID that is assigned automatically, starting with 0. Unless you change the system definition files, all default fixed-wing aircraft have one emitter with ID 0.
Setting the State of Simulation Objects — Engagement Results
To turn on electromagnetic emissions:
Select the simulation object.
Choose Set Sensors Emitter. The Emitter dialog box opens.
Type the emitter ID. If the simulation object only has one emitter, its ID is 0. If it has more than one emitter, IDs get incremented by 1 for each additional emitter. There is no way to identify the emitter ID for a particular emitter, so you will have to use a trial-and-error approach to identify the correct emitter ID to use.
In the Emitter list, select On.
An engagement result is a a text string that gets included in entity state update messages that get sent over the network. The purpose is for a human participant to comment on the current state of a simulation object as a simulation progresses. Once specified, the text string continues to get sent until the expiration time is reached or a new engage- ment result is set.
To set engagement results:
Select the simulation object.
Choose Set Engagement Engagement Results. The Engagement Results dialog box opens.
Specify the engagement result. This can be any text you want to enter.
Set the expiration time in days and hours:minutes:seconds.
Click OK.
Setting the State of Simulation Objects — Equipment Pacing/Tracking
To specify pacing or tracking for a unit’s equipment:
Select the simulation object.
Choose Set Disposition Equipment Pacing/Tracking. The Equipment Pacing/Tracking dialog box opens.
Select the check box for each type of equipment for which you want to specify pacing or tracking.
For each selected ammunition type, select an option from the list.
Click OK.
You can set the resources for a simulation object in an aggregate-level scenario.
To set the level of food, water, fuels, and lubricants:
Select the simulation object.
Choose Set Disposition Food, Water, Fuel, Oil and Lubricant. The Food, Water, Motor-Gas, Aviation-Fuel, Diesel Fuel, Oil, Lubricant dialog box opens.
Select the check box for each type of resource you want to specify.
For each selected resource type a value.
Click OK.
Setting the State of Simulation Objects — Force
To set pacing and tracking for food, water, and fuels, and lubricants:
Select the simulation object.
Choose Set Disposition Food, Water, Fuel, Oil and Lubricant Pacing/Tracking. The Food, Water, Motor-Gas, Aviation-Fuel, Diesel Fuel, Oil, Lubricant Pacing/Tracking dialog box opens.
Select the check box for each type of resource for which you want to specify pacing or tracking.
For each selected resource select an option from the list.
Click OK.
When you change a simulation object’s force, its:
Echelon ID changes to reflect the new force.
Icon changes to the appropriate force color and type.
Force ID changes.
The entity enumeration does not change.
To set the force of a simulation object:
Choose Set Disposition Force. The Force dialog box opens.
Select a force from the list.
Click OK.
Setting the State of Simulation Objects — Formation
VR-Forces supports the following formations:
Column (default)
Line
Wedge
Vee
User-defined formations.
Formations are defined in formation files in the directory ./data/simulationModel- Sets/<model_set>/vrfSim/formation. Formation files have the extension .frm. In addition to the named formations provided by MAK, VR-Forces supports user-defined forma- tions. If you create a new formation in the Simulation Object Editor, it automatically gets added to the formation list for the unit types that support it.
The vee and wedge formations provided with VR-Forces place the unit leader at the end of one of the arms of the formation. If a unit has fewer than seven or eight members, it will not be symmetrical.
If you set the formation for an aggregated unit, the unit remembers the formation and uses it the next time it disaggregates.
To set a unit’s formation:
Choose Set Unit Formation. The Formation dialog box opens.
In the Formation list, select the formation that you want the unit to use.
Click OK.
For information about configuring formations and about how to create user-defined formations, please see “Configuring Formations,” on page 73-2.
Setting the State of Simulation Objects — Health
The Heading request instantly sets a simulation object’s heading. If you want a simula- tion object to move to a new heading by pivoting or executing a K-turn, use the Turn To Heading task. You can also set a simulation object’s heading manually. For details, please see “Specifying an Object’s Heading Dynamically,” on page 16-17.
To set a simulation object’s heading:
Select the simulation object.
Choose Set Position Heading, or click the Heading button ( ) on the Sets Toolbar. The Heading dialog box opens. It displays the simulation object’s current heading.
In the Heading text box, type a heading, in degrees.
In the Relative To list, select one of the following options:
North. Turn to the specified absolute heading.
Current Heading. Turn the specified number of degrees relative to the current heading.
Host (if embarked). If embarked, turn to the specified heading relative to the host simulation object.
Click OK.
Health is a value based on a simulation object’s total personnel, equipment, and weapons. The Health set data request lets you restore personnel to their full values and set the overall health of the simulation object. For details about simulation object health, please see “The Aggregate Warfare Model,” on page 23-2.
To set a simulation object’s health:
Select the simulation object.
Choose Set Disposition Health. The Health dialog box opens. It displays the current state of personnel, equipment, and weapons.
To restore all personnel, select Reset Kill, Captured, Wounded, Missing.
To specify the overall health of the simulation object, adjust the Health slider or type a number in the Health box. As you move the slider to the left, the amount of personnel, equipment, and weapons decreases.
Click OK.
Setting the State of Simulation Objects — IFF
Friendly fixed-wing entities can model a NATO Identification Friend from Foe (IFF) transponder.
i Mode 5 and mode C are equivalent.
The dialog box does not force you to enter valid codes. It truncates
invalid entries to the correct length (but not necessarily valid data).
When you open the dialog box, it reflects the current IFF settings for the entity, if any.
You can view an entity’s IFF settings on the IFF tab of its Information dialog box.
To set the IFF transponder for a fixed-wing entity that is configured with an IFF controller:
Select the entity.
Choose Set Sensors IFF. The IFF dialog box opens (Figure 34-1).
Complete the IFF dialog box.
Setting the State of Simulation Objects — Lase Autonomous
If a simulation object is invulnerable, it does not take damage from munitions.
To set a simulation object to be invulnerable:
Select the entity.
Choose Set Disposition Invulnerable. The Invulnerable dialog box opens.
Select an option from the list.
The Jam Targets set data request orders an aircraft to jam specific targets or all simula- tion objects within its jamming beam. This set data request does not affect the simula- tion. It sends update messages that can be used by other applications in a simulation.
To jam targets:
Choose Set Sensors Jam Targets. The Jam Targets dialog opens.
In the Mode group box, select All Entities in Beam or Selected Entities.
If you selected Selected Entities, select the targets you want to jam.
Click OK.
By default, entities with laser capability lase targets autonomously as part of the built-in target acquisition and firing process. You can specifically enable and disable autono- mous lasing.
To enable or disable autonomous lasing:
Select the entity.
Choose Set Laser Designator Lase Autonomous. The Lase Autonomous dialog box opens.
The Lase Autonomous dialog box does not show the current lasing state of the entity.
Select an option from the list (Off or On).
Click OK.
Setting the State of Simulation Objects — Laser Code
The Laser Code set data request sets the code for laser beams sent by an entity and the code that the entity’s missiles seek when they fire. By default, VR-Forces calculates a laser code for each laser-capable entity when it is created. You can change the laser code to a code of your choice. For information about the consequences of setting laser codes, please see “Lasing Targets,” on page 9-15.
To specify an entity’s laser code:
Select the entity.
Choose Set Laser Designator Laser Code. The Laser Code dialog box opens.
Type a number between 111 and 8888, using only the digits 1-8.
Click OK.
To move a simulation object instantly from one place to another, you can set its loca- tion or you can drag it to a new location. For information about dragging simulation objects, please see “Dragging an Object to a New Location,” on page 16-19. For ground entities, specifying an altitude lets you place an entity at different levels (floors) in building features.
To set the location for a simulation object:
Select the simulation object.
Choose Set Position Location. The Location dialog box opens. It displays the simulation object’s current location. The cursor changes to input mode.
Click on the terrain where you want to move the simulation object, or enter the coordinates of the location in the Location dialog box.
Optionally, set the altitude, as described in “Specifying an Object’s Altitude,” on page 16-14.
Click OK.
Setting the State of Simulation Objects — Morale
When you set a unit’s MOPP level, the MOPP level changes instantly. To change MOPP level over time, use the Change MOPP Level task.
To set the MOPP level:
Select the simulation object.
Choose Set Disposition MOPP Level. The MOPP Level dialog box opens.
Select an option from the list.
Click OK.
Choose Set Disposition Morale. The Morale dialog box opens.
Adjust the slider or type a value from 0 through 100.
Click OK.
Setting the State of Simulation Objects — Navigation Preferences
When an entity is set to Prefer Roads, the entity gives preference to all segments along the preferred graph over those on the non-preferred movement graph. This is typically used to have vehicles prefer movement along roads, rather than cutting across open terrain, even if the distance along roads is longer.
If the movement mode is Avoid Roads, entities try not to move along roads. If they must cross a road, they take the shortest path across the road.
You can configure an entity to start up with a navigation preference or to ignore roads by editing the initial-road-preference parameter in the navigation-preference controller in the movement system definition file for this entity type.
To set navigation preferences:
Select the entity.
Choose Set Action Navigation Preferences. The Navigation Preferences dialog box opens.
To have the entity take road data into account, select Prefer Roads or Avoid Roads from the Navigation Preferences list. To have an entity plan its path as if there were no road data, select Ignore Roads.
Click OK.
You can set the notification level for entity console messages without opening the Infor- mation dialog box. You can also set the notification level for combat engineering objects in aggregate-level scenarios.
To set the notification level:
Choose Set Other Notify Level. The Notify Level dialog box opens.
Select a notification level in the list.
Click OK.
Setting the State of Simulation Objects — Percent Complete
The ordered speed is the speed at which you want a simulation object to move. It may not move at that actual speed due to soil type, slope, and so on. In aggregate-level scenarios, speed may be affected by modifiers. If you set the speed while a simulation object is moving, it accelerates or decelerates from the current speed to the new ordered speed, if it can.
A negative value causes the entity to go backwards if it supports backwards movement.
Regardless of the speed that you enter, a simulation object’s speed cannot exceed the value set by the max-speed parameter in the object parameter database.
The Speed request sets the ordered speed of a fixed-wing entity in its current context – air or ground. The entity will not exceed the maximum speed for that context. However, if the maximum allowable ground speed is greater than the lift speed of the entity, and you assign an ordered speed greater than the lift speed, when the entity reaches that speed, it tries to take off.
If you want a simulation object’s speed to change instantly, use the Current Speed set data request (“Current Speed,” on page 34-14).
If a simulation object does not have a task, this set data request has no effect.
To set the ordered speed of a simulation object:
Select the simulation object.
Choose Set Action Ordered Speed. The Ordered Speed dialog box opens.
In the Ordered Speed text box, set the speed.
Click OK.
Percent Complete lets you set the degree of completion for combat engineering objects in aggregate-level scenarios.
To set the percent complete:
Select a combat engineering object.
Choose Set Disposition Percent Complete. The Percent Complete dialog box opens.
Adjust the slider or type a value in the box.
Click OK.
Setting the State of Simulation Objects — Posture (Unit)
You can set the posture of a simulation object in an aggregate-level scenario. The posture changes instantly. To change posture over time, use the Change Posture task.
To set a simulation object’s posture in an aggregate-level scenario:
Select the simulation object.
Choose Set Disposition Posture. The Posture dialog box opens.
Select an option from the list.
Click OK.
Setting the State of Simulation Objects — Posture (Human)
A human entity (civilian or dismounted infantry) has a posture that determines its posi- tion when it is not moving and its type of movement when it is moving. Table 34-1 lists the position and movement relationships for each posture.
Table 34-1: Posture relationships
Posture | When it is not moving, it is: | When it is moving, it is: |
standing | standing | walking or running |
kneeling | kneeling | crawling |
prone | prone | crawling |
running | standing | walking or running |
walking | standing | walking or running |
crawling | prone | crawling |
parachuting | standing | walking or running |
jumping | standing | walking or running |
sitting | standing | walking |
squatting | prone | crawling |
crouching | prone | crawling |
wading | standing | walking or running |
For those postures listed as “walking or running”, VR-Forces sets the movement posture based on the entity’s speed.
If an entity does not support a particular posture, it is set to the closest supported posture.
Setting posture in the Lifeform State field of the Appearance dialog box has the same effect as setting the posture using the Posture set data request.
Some embarkation slots specify the posture of occupants.
To set a lifeform’s posture:
Select the lifeform.
Choose Set Appearance Posture. The Posture dialog box opens.
Select a posture from the list.
Click OK.
Setting the State of Simulation Objects — Preferred Targets
Units can target up to three simulation objects. By default, they target the three simula- tion objects that are most vulnerable to attack. If you want a simulation object to target specific simulation objects that it might not choose automatically, the Preferred Targets set data request lets you specify them as preferred targets.
To specify preferred targets:
Select a unit.
Choose Set Engagement Preferred Targets. The Preferred Targets dialog box opens.
Select up to three simulation objects.
Click OK.
Setting the State of Simulation Objects — Reorganize
The Radar Mode set data request lets you change the type of beam that an entity emitter publishes. By default, each fixed-wing aircraft has one emitter that has two beam types, search and track.
Figure 34-2 illustrates the difference in appearance between the beams for the two radar modes, in the 2D view. (The beams are not displayed unless you set emitters to be on.)
Search Track
For more information about emitter beams, please see “Emitter,” on page 34-18 and “Configuring Emitters,” on page 74-2.
To set an entity’s radar mode:
Choose Set Sensors Radar Mode. The Radar Mode dialog box opens.
If the entity has more than one emitter, select the emitter ID you want to set in the Emitter ID list.
Select the mode in the Mode list.
To reorganize a unit:
Select the unit that you want to reorganize.
Choose Set Unit Reorganize.
The change takes place immediately. For more information about reorganization, please see “Reorganizing Units,” on page 22-4.
Setting the State of Simulation Objects — Resources
To specify a resource value:
Select the simulation object.
Choose Set Disposition Resources. The Resources dialog box opens.
Select a resource from the Resource list. The dialog box displays the maximum amount of the resource allowed, as configured in the object parameter database.
Specify a value for the resource.
Click OK.
To set pacing and tracking for a resource:
Select the simulation object.
Choose Set Disposition Resource Pacing/Tracking. The Resources Pacing/Tracking dialog box opens.
Select Resources.
Click OK.
Setting the State of Simulation Objects — Resupply Mode
Restoring a simulation object returns its resources to the values specified in the object parameter database. If the simulation object is destroyed, it returns it to life.
To restore a simulation object:
Select the simulation object.
Choose Set Disposition Restore.
Resupply Mode specifies one of the following resupply modes for simulation objects in an aggregate-level scenario:
None. The simulation object does not resupply itself.
From Supply Units. When a resupply unit is in range, the unit gets supplies from it.
From Self-Continuous. The unit resupplies itself continuously based on its resupply rate parameters. For details, please see “Logistics,” on page 23-13.
From Self-Periodic. The unit periodically resets all of its supplies, except health, to the base level. This level is reduced by health losses.
To specify the resupply mode:
Select the unit.
Choose Set Logistics Set Resupply Mode. The Resupply Mode dialog box opens.
Select a resupply mode from the Resupply Mode list.
If you select From Self-Periodic, specify the resupply period in the Periodic Resupply Period boxes.
Click OK.
Setting the State of Simulation Objects — Rules of Engagement
Rules of engagement specify the conditions under which a simulation object will fire at the enemy.
To specify the rules of engagement for a simulation object:
Select the simulation object.
Choose Set Engagement Rules of Engagement, or click the Rules of Engage- ment button 
) on the Sets Toolbar. The Rules of Engagement dialog box opens.
In the Rules of Engagement list, select the rule you want to apply.
Click OK.
A simulation object considers itself under fire if either of the following is true:
An “Entity Impact” detonation interaction that targeted this entity has recently (within underFireTime seconds (default 120)) been received.
Any detonation has happened within underFireDistance (default 1000 meters) of this entity.
There is no attempt to return fire specifically at the attacking entity. If a simulation object thinks that it is under fire, it will fire at any enemies that it can target.
The underFireTime and underFireDistance parameters are part of the under-fire- determination-sensor component in a simulation object’s platform (OPE) file.
Setting the State of Simulation Objects — Sector of Responsibility
A simulation object's sector of responsibility is used with detection tables to determine the priority of targets. Normally, the priority of targets that are outside a simulation object's sector of responsibility is lower than the priority of targets in its sector of responsibility. For information about the target detection tables, please see “Detection Tables,” on page 71-14.
You must specify a sector center and a sector size. Sector center is the center of the area you wish to designate, and sector size is the size of the area, both in degrees. Degrees are measured as 0 to the front (based on the heading), increasing clockwise. If the Turret Scan Controller is mounted on an entity with an articulating turret, then the turret scans the sector of responsibility specified. Sector center is the midpoint of the area.
Figure 34-3 illustrates these parameters. The sector size is approximately 140 degrees, a bit less than half the circle. The sector center is at 0 degrees.
i The default sector of responsibility is 90 degrees, centered at zero degrees.
area center
sector size
entity
Figure 34-3. Sector of responsibility parameters
To set a simulation object’s sector of responsibility:
Select the simulation object.
Choose Set Engagement Sector of Responsibility. The Sector of Responsibility dialog box opens.
In the Size text box, set the size of the area to be scanned, in degrees.
In the Center text box, set the center of the scan area, in degrees.
Click OK.
Setting the State of Simulation Objects — Sensor Aim
The Sensor Aim set data request specifies where a gimbaled sensor should look.
You can also aim a gimbaled sensor from the Sensor View control panel. For details, please see “Controlling the Sensor View,” on page 51-10.
To aim a sensor:
Select an entity that has a gimbaled visual sensor.
Choose Set Sensors Sensor Aim. The Sensor Aim dialog box opens.
Choose an aiming option and provide the required input, as follows:
Aim at Point. Click on the terrain or type in coordinates. By default, the altitude is the altitude of the entity.
Aim at Object. Select the simulation object to aim at.
Aim at Angle. Specify the Azimuth (the horizontal angle relative to the sensing entity) and elevation (the vertical angle that the sensor aims at).
Scan. By default, the sensor scans back and forth within a 180 degree range. You can change the elevation and azimuth angles in the gimbaled sensor system defi- nition file.
Click OK.
The Sensor Enabled set data request lets you enable and disabled individual sensors on a simulation object.
To enable or disable a sensor:
Select the simulation object.
Choose Set Sensors Sensor Enabled. The Sensor Enabled dialog box opens.
In the Sensor list, select the sensor you want to enable or disable, or select All.
In the Enabled list, select Yes or No.
Click OK.
Setting the State of Simulation Objects — Sensor Zoom
You can also zoom a gimbaled sensor from the Sensor View control panel. For details, please see “Controlling the Sensor View,” on page 51-10.
To zoom a visual sensor:
Select the entity whose sensor you want to zoom.
Choose Set Sensors Sensor Zoom. The Sensor Zoom dialog box opens.
If the entity has more than one sensor, in the Sensor list, select the sensor you want to zoom.
Type the zoom level you want or drag the slider.
Click OK.
Setting the State of Simulation Objects — Sonar Depth
The sonar stays at this depth regardless of the altitude or depth of the entity. If you set the depth to be the depth of the entity with the Use Entity Depth option, it has the effect of retracting the sonar. If you set the sonar to the depth of the entity and the entity changes depth, the sonar stays at the assigned depth.
To set sonar depth:
Select the entity.
Choose Set Sensors Sonar Depth. The Sonar Depth dialog box opens.
Specify the depth.
Optionally, select Use Entity Depth to set a dipped sonar to the depth of the entity.
Click OK.
Setting the State of Simulation Objects — Spot Reports
You can set spot reports on or off for all simulation objects (global setting) from the Spot Report Options page of the Application Settings dialog box. You can also set them for individual simulation objects. When you set spot reports on, it means that the simu- lation object sends them. Visualization of spot reports is enabled or disabled for the GUI as a whole on the Spot Report Options page. For more information about spot reports, including setting them globally, please see “Displaying Simulation Objects Based on Spot Reports,” on page 9-2.
You cannot set a unit in an entity-level scenario to send spot reports; you can only set spot reports for individual simulation objects. However, you can select multiple individual simulation objects and set spot reports for all of them at the same time.
To set spot reports on or off for a simulation object:
Select the simulation object.
Choose Set Sensors Spot Reports. The Spot Reports dialog box opens. If you are turning spot reports off, skip to step 5.
Select one of the following options:
Only to Front End. Do not send spot reports to other back-ends. This option can improve performance.
Broadcast. Send spot reports to all simulation objects.
Send to Specific Entities. Sends to specific simulation objects.
If you selected Send to Specific Entities, the simulation object list is enabled. Select the simulation objects to which you want this simulation object to send sport reports.
Select an option from the Spot Reports Enabled list. If you choose On or Off, the setting persists regardless of the global spot report setting. If you want the simula- tion object to use the global spot report setting, choose Use Global Setting.
Click OK.
Setting the State of Simulation Objects — Superior
To specify a simulation object’s superior:
Select the simulation object.
Choose Set Other Superior. The Superior dialog box opens.
Optionally, filter the list.
Select the unit that you want to be this simulation object’s superior. If you want to move the simulation object out of a unit to the force level, select the Set Force As Superior check box.
Click OK.
The Supplying set data request sets a supply unit to stop providing supplies or to start providing supplies.
To stop or start a supply unit providing supplies:
Choose Set Logistics Supplying. The Supplying dialog box opens.
Select Stop or Start.
Click OK.
To set an entity to be surrendered:
Select the entity.
Choose Set Disposition Surrendered. The Surrendered dialog box opens.
Select an option from the list.
Click OK.
Setting the State of Simulation Objects — Target
To synchronize laser codes:
Select the entity that has a laser-guide weapon.
Choose Set Laser Designator Synchronize Laser Code. The Synchronize Laser Code dialog box opens.
Select the lasing entity that you want this entity to synchronize with.
Click OK. The laser code for the selected entity is changed to match that of the lasing entity.
You can command an entity to specifically target another entity. For this set data request to be effective, the target must be visible to the targeting entity. When you set a target, you override the priorities set by the target selection controller. If the specified target is in the list of candidate targets, it gets the highest priority as a target. However, if the specified target is not visible as a target to the targeting entity, the entity fires at the other available targets. It does not keep looking for the specified target.
To set an entity’s target:
Select the entity.
Choose Set Engagement Target. The Target dialog box opens.
Optionally, filter the entity selection list.
In the Target list, or on the terrain, select the entity to target.
Click OK.
Setting the State of Simulation Objects — Tasked by Superior
You can order a simulation object that is part of a unit, and which is executing its own plan or is conducting an independent task, to stop executing those tasks and take commands from its unit. When you order a simulation object to be tasked by its supe- rior, it stops conducting independent tasks and waits for the next order from the unit. (It does not execute the unit’s current task, if any.) For more information about being tasked by superior, please see “Independently Tasking Unit Members,” on page 26-12.
To order a simulation object to be tasked by its superior:
Select the simulation object.
Choose Set Other Tasked by Superior.
To enable or disable user of tracers:
Select the entity for which you want to enable or disable use of tracers.
Choose Set Engagement Tracer Use. The Tracer Use dialog box opens.
Choose an option from the User Tracers list.
Click OK.
To set a unit’s aggregation state:
Select the unit.
Choose Set Unit Unit State. The Unit State dialog box opens.
Select the desired state from the list.
Click OK.
Setting the State of Simulation Objects — Weapons Pacing/Tracking
Tracking indicates that the commander is interested in the status of this item. These designations do not affect the simulation. They are reported for use by external systems.
To set pacing or tracking for a unit’s weapons:
Select the simulation object.
Choose Set Disposition Weapons Pacing/Tracking. The Weapons Pacing/Tracking dialog box opens.
Select the check box for each weapon for which you want to specify pacing or tracking.
For each selected weapon type, select an option from the list.
Click OK.
Setting the State of Simulation Objects — Weapons Pacing/Tracking
This section describes how to write plans.
VR-Forces has two kinds of plans, global plans and individual plans. Both kinds of plans can assign tasks and set data requests to a simulation object. Plans can also contain commands that create or delete simulation objects and tactical graphics. The commands in a plan can be conditional, that is, they will be executed only if a condi- tion is satisfied. When you open a scenario, it is in pause mode (unless you start it with the -l command line option). When you start the simulation, the plans start executing.
Global plans are created and executed independently of any particular simulation object. Commands sent to simulation objects from a global plan affect them as if they received an independent task through the Task menu — they interrupt the current task, if any, and cause the simulation object to abandon its plan, if it has one.
An individual plan is a set of statements that order a particular simulation object to complete a sequence of tasks, change its state, or both. The simulation object carries out the tasks in order unless it is interrupted by an independent task or global command.
A simulation object owns its individual plan. Changing its name, echelon relationship, or force does not change its plan.
If a simulation object does not have a plan, it does not mean that it has nothing to do. A simulation object may be assigned tasks by its superior in the force hierarchy. It can also be assigned tasks interactively from the front-end. If you want a simulation object to take planned actions independently of those assigned by its superior, you need to add statements to its plan.
VR-Forces Users Guide
Section VI - Plans
VI-1
Plans — Introduction to Plans
You can view a simulation object’s plan at any time in the Plan window. The task that a simulation object is currently executing is highlighted. A simple plan might look like the following:
Move-To Waypoint:"red point" Wait-Duration Seconds-ToWait:900 Move-To Waypoint:"white point"
Set Engagement-Rules="Fire-at-will"
!
!
You can edit plans while a simulation is running. However, when you change a plan during a simulation, the simulation object starts executing the plan from the beginning, which may cause its activities to be out of synchronization with the other simulation objects in the simulation.
Section VI - Plans
VI-2 VT MAK
This chapter describes plans and plan concepts.
Introduction to Individual Plans and Global Plans 35-2
Considerations for Creating Plans 35-17
Considerations for Using Triggers 35-17
Using Concurrent Tasks in Plans 35-18
Using the Tasked-By-Superior Request in a Plan 35-18
Following Simulation Objects 35-18
Planning Tasks for Aircraft 35-19
Using Non-VR-Forces Simulation Objects in Plans 35-19
Plan Concepts — Introduction to Individual Plans and Global Plans
A plan contains one or more statements that get executed by VR-Forces without human intervention. You build these statements in dialog boxes. VR-Forces writes the state- ment to the plan, so you do not have to worry about syntax errors in your statements when you first create them. However, you must understand the meaning of individual commands and parameters and the implications of how you order them, to make sure that a plan does what you want it to do.
VR-Forces supports two types of plans – individual plans and global plans. They have the following characteristics:
Individual plans apply to a specific simulation object. They contain tasks and set data requests that are specific to the simulation object and which get executed sequentially. The sequence of task execution can be interrupted by receipt of a task from an external actor (a global plan command or independent task). The task sequence can also be interrupted if a trigger (a form of conditional statement) or a reactive task is activated.
!
!
Individual plans can include global commands (which are described later in this section). However, you must be careful not to use global commands, tasks, or sets for a simulation object in its own plan when you really want simulation object-specific tasks or sets. Sending a simulation object a global command, even from within its own plan, terminates its plan.
Global plans are independent of any simulation object. The statements in a global plan affect the scenario as a whole (create and delete object commands) or a specific simulation object (task and set commands). Tasks sent to a simulation object from a global plan have the same effect on the simulation object as independent tasks assigned by a human player. They interrupt any task that the simulation object is engaged in and terminate its plan. Furthermore, if a global plan has a series of tasks for the same simulation object, they get sent in order without regard to completion of the previous task (as if you issued a series of commands from the Task menu, one immediately after another). In such a case, only the last command sent is likely to be completed.
Figure 35-1 shows a global plan and an individual plan. Note that the individual plan window (on the right) is tied to a particular simulation object (shown in the title bar).
Plan Concepts — Introduction to Individual Plans and Global Plans
Figure 35-1. Global plan and individual plan
Many of the statements used in plans set a parameter or direct a simulation object to perform a specific task unconditionally. However, the plan language also includes conditional statements. A conditional statement specifies a condition and a block of plan statements that get executed if the condition is true. VR-Forces supports the following conditional statements:
If. An If statement is evaluated once, when the plan execution flow arrives at the statement. If the condition is true at that point, VR-Forces executes the statements in the If block. For details, please see “The If Statement,” on page 35-6.
Trigger. A trigger statement lets you plan for a condition without knowing in advance when the condition will occur. It specifies a condition that is evaluated continuously by VR-Forces. If the condition becomes true, VR-Forces executes the statements in the trigger block. For details, please see “Triggers,” on page 35-7.
While. A While statement executes a block of statements repeatedly while a condition remains true. VR-Forces evaluates the condition when the plan first arrives at the While statement. If the condition is true, it executes the statements in the block. When it completes the statements, it evaluates the condition again. If it is still true, VR-Forces executes the statements again. It continues to do so as long as the While condition is true. For details, please see “While Statements,” on page 35-9.
Wait Until. A Wait Until statement causes a simulation object to wait in place until the condition becomes true. Then the simulation object executes the statements in the Wait Until block. After completing the statements in the block, it moves to the next statement in the plan. For details, please see “Wait Until Statements,” on page 35-9.
The conditions that can be tested by conditional statements are:
Is a simulation object in a given area? (Entity In Area)
Is a simulation object to the left of a phase line? (Entity Left of Line)
Is a simulation object destroyed? (Entity Destroyed)
Is a simulation object under fire? (Entity Under Fire)
Has a simulation object located a target? (Entity Has Target)
Has a simulation object’s embarkation state changed? (Entity Embarked)
Is a simulation object above or below a specified altitude? (Entity Altitude)
Has this simulation object detected another simulation object? (Entity Detected)
Has this simulation object received a text message? (Receive Text Message)
Has an engineering object been breached? (Engineering Object Breached)
Has this simulation object received a missile approach warning? (Missile Approach Warning)
Is a scenario event in process or concluded? (Scenario Event)
Has a lifeform surrendered? (Lifeform Surrendered)
Does a lifeform have a particular DI-Guy animation? (Entity Di-Guy Animation Check)
Does a lifeform have a particular DI-Guy appearance? (Entity Di-Guy Appearance Check)
Is a random probability true? (Random)
Is a resource for this simulation object at a certain level? (Resource)
Is the simulation time greater than or less than a specific elapsed time? (Sim Time)
Is the simulation date and time a certain value? (Simulation Date/Time)
Is a tactical graphic active? (Tactical Graphic Active)
Conditional statements can test for True and False, and can include the logical opera- tors AND, OR, and NOT.
For details, please see “Conditional Tests,” on page 35-10.
An If statement tests a condition. It only tests the condition once.
Do not use an If statement to test for receipt of a message or some other circumstance that does not represent a simulation object’s state. VR-Forces does not keep a record of events and such a test will almost always evaluate to false. Use a trigger to test for conditions that do not evaluate simulation object state.
An If block consists of:
The word If.
A condition to be evaluated.
A block of statements.
An else statement.
Optionally, statements for the else condition.
An endif statement.
If the condition is true at the moment the If statement is evaluated, control passes to the first statement of the If block. If the condition is false, control passes to the first statement in the else block, if you have one, or to the first statement after the complete If block if you do not have an else block. You can nest If statements within If statements. The syntax is as follows:
If (condition) then
zero_one_or_more_statements
else
zero_one_or_more_statements
endif
When VR-Forces reaches the end of the block of If or else statements, control passes to the first statement after the If statement.
The Add Conditional Expression dialog box ensures that you have the correct syntax. It does not ensure that your If block makes logical sense.
When you create a trigger, it is not automatically added to the plan’s execution sequence. You must register a trigger before VR-Forces will test it. (If you have a programming background, it may be helpful to think of triggers as functions or subrou- tines that you write separately and then call from elsewhere in a plan. Extending the analogy, a trigger is always local to its plan.)
When you register a trigger, VR-Forces checks the condition. If the condition is true, control passes to the first statement in the trigger. If the condition is false, VR-Forces continues to the next statement in the plan. It continues to check the trigger condition periodically. If at any point, the condition evaluates as true, control passes to the block of statements associated with the trigger.
When you create a trigger, you can specify that it interrupt the current task or that it suspend and resume the current task.
If you specify that a trigger interrupt the current task, task execution proceeds as follows:
If the tasks in a trigger are not mutually exclusive with the current task, or if the trigger only has set data request statements, the trigger’s statements are executed and the current task continues. For more information about this case, please see “Using Triggers That Do Not Have Mutually Exclusive Tasks,” on page 35-17.
After the tasks in the trigger block are completed, control returns to the next state- ment in the simulation object’s plan after the one that was interrupted by the trigger.
If you specify that a trigger suspend the current task, task execution proceeds as follows:
If a trigger contains any tasks that are mutually exclusive with the currently executing task, the current task is suspended and the statements in the trigger are executed.
If the tasks in a trigger are not mutually exclusive with the current task, or if the trigger only has set data request statements, the trigger’s statements are executed and the current task continues. For more information about this case, please see “Using Triggers That Do Not Have Mutually Exclusive Tasks,” on page 35-17.
After the tasks in the trigger block are completed, the suspended task is resumed, if possible. There may be cases where the previous task is no longer meaningful due to changes in the scenario.
The location of a trigger in a plan has an important affect on its functioning. For a discussion about where to place triggers, please see “Deciding Where to Put Triggers,” on page 35-17.)
Figure 35-2 illustrates the process when a trigger has a task that is mutually exclusive with the current task and you have specified that the current task be discarded. After the tasks in the trigger are completed, control returns to the next statement in the simula- tion object’s plan. If the simulation object was in a While loop when the trigger fired, it returns to the next statement in the While block.
Register (Resource(fuel) <50%)
.
.
.
Move-Along Route:"main st."
Move-To Waypoint:"waypoint delta"
Register (Resource(fuel) <50%)
.
.
.
Move-Along Route:"main st."
Move-To Waypoint:"waypoint delta"
Trigger
Execute task block in trigger: Move-To Waypoint:"fuel depot"
Current 
task
Trigger fires
Abandon task
After the trigger block completes, control returns to the next statement in the plan.
Figure 35-2. Flow of control for triggers
By default, after a trigger fires, it is removed from the list of registered triggers. If you want to continue to test for the same condition, you must reregister the trigger. You can design the plan in such a way that the trigger is registered again. Alternatively, when you create a trigger, you can specify that it reregister automatically.
An alternative to using triggers in a plan is to write a reactive task. For information about reactive tasks, please see Chapter 32, Creating Scripted Tasks and Sets.
A While statement consists of:
The word While.
A condition to be evaluated.
A block of statements.
An endWhile statement.
If the condition is true at the moment the While statement is reached, control passes to the first statement of the While block. If the condition is false, control passes to the first statement after the complete While block. You can nest While statements within other conditional blocks.
When VR-Forces reaches the end of the While block, it evaluates the condition again. If the condition is still true, VR-Forces executes the statements again. If it is false, control passes to the first statement after the While block.
VR-Forces re-evaluates a While condition only after it has executed all of the statements in the block. If the condition becomes false while VR- Forces is executing statements in the block, VR-Forces continues to execute all statements because it does not re-evaluate the condition until it completes the While block.
If you put a continuous task such as Wait or Patrol Between in a While block, it is possible that the condition will never be re-evaluated, because these tasks never finish.
A Wait Until statement consists of:
The words Wait Until.
A condition to be evaluated.
If the condition is true at the moment the Wait Until statement is reached, the simulation object continues to the next task in the plan. If the condition is false, the simulation object waits in place. VR-Forces continues to check the condition periodi- cally until the condition becomes true or the simulation object is tasked by some other form of input, such as a trigger or independent task.
If a Wait Until state is interrupted by a trigger and the trigger’s Interrupt Current Task check box is not selected, the plan returns to the Wait Until state after the trigger’s tasks are completed. If the trigger’s Interrupt Current Task check box is selected, the plan moves to the statement after the Wait Until.
If the condition becomes true, control passes to the next statement in the plan.
If there is no simulation object with the specified name, the result is always false.
If the specified simulation object is destroyed, the condition might never be satis- fied. Your plan should take this possibility into account.
The Detect Entity condition tests to see if this simulation object has detected another simulation object at a particular identification level. The identification levels are Detected, Classified, Identified, and Full Knowledge. Identification levels are deter- mined by the detection probability configuration files, based on the distance between the detecting simulation object and the target and for how long the simulation object has been detected. For details about the detection probability files, please see “Detec- tion Tables,” on page 71-14.
i This condition is not supported in global plans.
Engineering Object Breached
The Engineering Object Breached condition returns true if the specified engineering object has been breached. (Aggregate-level scenarios only.)
Entity Destroyed returns true if the specified simulation object is destroyed.
The definition of destruction for a unit is implementation specific. For the entity-level models provided with VR-Forces, disaggregated units are considered to be destroyed when all members of the unit are destroyed.
If you have implemented units locally using the VR-Forces Toolkit, they could have a different definition of destroyed.
The Entity Di-Guy Animation Check condition tests the current DI-Guy animation for a lifeform. This condition may be useful if you are scripting a series of animations. For example, if a particular entity is using a threatening or hostile animation, you might want to have other simulation objects respond a certain way.
The Entity Di-Guy Appearance Check condition tests the current DI-Guy appearance for a lifeform. This condition may be useful if you are scripting a lifeform’s interaction with another lifeform based on ethnicity or how they are dressed.
Entity Embarked returns true if the named simulation object is embarked.
Entity Has Target returns true if the simulation object specified in the condition identi- fies a target. For example, consider the entities in Figure 35-3. The condition in M1A2 1’s plan is true when BMP 1 has a target, not when M1A2 1 targets BMP 1.
M1A2 1 BMP 1
Plan for M1A2 1
If(Entity-Has-Target:”BMP 1”) do something
endif
Plan for M1A2 1
If(Entity-Has-Target:”BMP 1”) do something
endif
Figure 35-3. Entity Has Target condition
If a simulation object’s rules of engagement prevent it from firing, this condition does not return true when the simulation object identifies a target.
Entity In Area returns true if the simulation object reports that it is in the named area. You can use the NOT operator, to test whether a simulation object is outside the area.
If a simulation object enters an extruded area, VR-Forces does a 2D check first, to see if it is in the area. Then it checks the simulation object’s altitude to see if it is within the area’s volume.
If you have a plan in which you are testing for entities in an area and destroying them as they enter it, the Exclude Destroyed Simulation Objects option lets you reregister a trigger and only test for entities that have not been destroyed.
A simulation object is considered to be to the left of a phase line if it is on the left side of an infinite extension of the phase line as viewed from a point on the line facing in the direction of the line. For a description of phase line direction, please see “Phase Lines,” on page 37-4.
Entity Under Fire returns true if the simulation object is under fire.
The Lifeform Surrendered condition tests to see if a lifeform entity has surrendered (using the Surrendered set data request).
The Missile Approach Warning condition returns true if a hostile missile is within the specified distance of this simulation object. This condition is not available in global plans.
You can use the Random condition to randomly decide a simulation object's behavior at run time.
Percentage – A floating point probability percentage value between 0% (zero) and 100%. Random returns true if a random number between zero and 100 is less than or equal to the specified value.
If you use the Random condition, consider the following issues:
Random is not very useful in triggers, since triggers may evaluate their condition expressions as often as once per tick. This means that a trigger expression of “Random Probability:50%” is likely to fire within the first couple of times it is eval- uated. Therefore, we recommend that you not create triggers that are based on a random condition.
If you use a random condition in a cascading sequence of If statements, and you want to ensure the correct probability distribution, be careful how you specify the percentage value. For example, randomly selecting one of three paths with equal probability would be done like this:
If (Random Probability:33.33%) then Move-Along Route:"1"
Else
If (Random Probability:50%) then Move-Along Route:"2"
Else
Move-Along Route:"3" Endif
Endif
The Receive Text Message condition tests to see if this simulation object has received a text message (sent by the Send Text Message task) that contains the text specified in the Receive Text Message dialog box. This condition is not available in global plans.
The Scenario Event condition returns true if the specified scenario event is in process or has completed.
The Sim Time condition returns true if the elapsed simulation time is greater than (Sim Time >) or less than (Sim Time <) the time specified in the statement. Sim Time is the elapsed simulation time in days, hours, minutes, and seconds.
The Simulation Date/Time condition returns true if the simulation date and time matches the specified value.
The Tactical Graphic Active condition returns true if a published tactical graphic is in the active state. For details about setting a tactical graphic’s state, please see “Active and Inactive Tactical Graphics,” on page 39-19 and “Activation,” on page 40-3.
You can use the following boolean operators in conditional expressions:
True.
False.
AND (expression, expression) – evaluates as true if both conditional expressions are true.
OR (expression, expression) – evaluates as true if either of the expressions are true.
NOT (expression) - evaluates as true if the conditional expression is false.
Plan Concepts — Plan Variables
Many tasks require you to specify a simulation object to act on, such as Fire on Target. Conditional tests, such as Entity Destroyed, require you to identify a simulation object to evaluate. However, you will not always know the name of the simulation object that you need to specify. Variables let you specify a simulation object without knowing its name. Plans can reference two variables:
Simulation Object. The Simulation Object variable references a simulation object that has been identified by a conditional test, such as Entity in Area or Entity Left of Line. For example, suppose that if an opposing force entity enters an area you want to fire at it. You can create a trigger using an Entity in Area condition. Then in the body of the trigger, you can insert a Fire at Target task that specifies the Simulation Object variable rather than the name of a specific entity.
Created Object. The Created Object variable references the most recently created object. For example suppose you create an object from a plan and do not give it a name. You can issue it a plan or refer to it using the Create Object variable. This variable refers to the most recently created object.
Plan variables are specific to each simulation object plan. A variable value in one plan does not affect the variable value in a different plan. Therefore, if you want to use the Created Object variable, you must create the object in the plan in which you want to use it. You could not, for example, create an object in a global plan and then reference it using the Created Object variable from a simulation object’s plan.
Once a variable has a value, you can use that variable in a plan as many times as you want to. However, you will need to keep track of plan logic that might change the value as the simulation object progresses through the plan.
For details about how to use variables in plans, please see “Using Plan Variables,” on page 36-25.
Plan Concepts — Viewing Plans
If the Plan window is collapsed (that is, the Trigger pane is not visible) and control passes to a trigger, the window automatically expands to show the tasks in the trigger that is being executed.
The task that a simulation object is executing is highlighted in the Plan window. When the simulation object completes its plan, a message is displayed in the status area at the bottom of the Plan window.
You can view the plans for as many simulation objects at a time as you want. In addi- tion to viewing plan status in the Plan window, you can view the current task on the Task Status page of the Information dialog box. The Last Selected Object panel also lists the currently executing task.
To view a simulation object’s plan:
Choose Objects Plan, or press p. The Plan window opens.
This section has tips for constructing plans including how to avoid problems that are hard to debug and how statements affect each other, with implications for how to orga- nize the statements in a plan.
Triggers are a versatile part of plans and you should have a good understanding of their intricacies before you use them.
You can also register a trigger inside a conditional block so that it gets registered only if a particular condition is true at a particular time.
For example, if you always want entity 1 to respond to entry of hostile forces into an area, put a trigger at the beginning of the plan. If you want entity 1 to respond to a hostile simulation object in an area only after the simulation has progressed for 15 minutes, nest the trigger inside another trigger that fires when Sim Time > 15 minutes.
A trigger does not have to have any task statements in its statement block. It could just have Set statements. Or, it could have sets and concurrent tasks. If a trigger block just has Set statements, it does not interrupt the task that the simulation object is executing when the trigger gets executed. The Set statements get executed while the simulation object is performing its task. This has the same effect as if you manually set the simula- tion object’s state while it was performing a task.
Using a trigger that just has Set statements can be useful if you want to change a simu- lation object’s state under certain conditions, but do not know in advance when those conditions might exist.
If you are assigning tasks to simulation objects manually, you can give a simulation object a concurrent task while it is executing some other task. You cannot do this directly in a plan, because you cannot assign two tasks at the same time. A plan always waits for its current task to complete before it starts the next task, even if the next task does not conflict with the current one. If you want to assign a concurrent task in a plan, you must use a trigger. If a trigger that just has a concurrent task fires, the simulation object will execute the concurrent task and continue with its existing task. If the trigger has other tasks, the behavior will be as expected for triggers.
For more information about concurrent tasks, please see “Concurrent Task Execution,” on page 26-5.
As an alternative to using plan triggers to automatically assign concurrent tasks, you can create reactive tasks. For information about reactive tasks, please see “Reactive Tasks,” on page 26-12.
If you tell two or more simulation objects to follow another simulation object, do not give them the same offset values. If the followed simulation object stops, one follower will arrive at the specified offset position and stop, while the others will circle the loca- tion because they cannot all occupy the same space.
Rotary-wing aircraft have some terrain-following capacity, but it has some limitations. So if you assign aircraft an altitude that is lower than the terrain at some point along a route or the path they must follow to reach a waypoint, they will crash into the terrain. View the terrain profile for a route to see if it intersects the terrain.
You should also bear in mind that a fixed-wing aircraft’s ability to follow a route depends on the speed of the aircraft, its size, and the distance and angle between the points of the route.
You can use a non-VR-Forces simulation object as a parameter in a plan, for example, following a remote simulation object, or testing to see if a remote simulation object is in an area.
VR-Forces does not recognize remote units as units, so it cannot check their children. Remote units are ignored by the simulation engine.
Referring to remote entities by their marking text may have unpredict- able results if there is more than one remote simulation object with the same marking text.
If you include a non-VR-Forces simulation object in a plan you must ensure that the remote simulator uses the same name for the simulation object in future runs.
This chapter explains how to combine tasks, set data requests, global commands, and conditions into plans.
Writing Plans for Simulation Objects 36-3
Adding a Task or Set Data Request to a Plan 36-4
Adding an If Block to a Plan 36-5
Adding a While Block to a Plan 36-6
Adding a Wait Until Statement to a Plan 36-6
Adding a Trigger to a Plan 36-7
Cleaning Up Unused Triggers 36-9
Deleting Statements from a Plan 36-10
Saving Changes to a Plan 36-10
Building Condition Statements 36-11
Building a Condition Statement that has One Condition 36-11
Building a Complex Condition 36-14
Editing Condition Statements 36-21
Specifying Names or Patterns in Condition Statements 36-22
Controlling When Global Plans Run (Quick Launch) 36-28
Opening an Information Dialog Box for a Global Plan 36-28
Adding Commands to a Plan 36-29
Writing Plans
Adding Tasks and Sets from the Commands Menu 36-30
Sending Console Messages 36-33
Creating Objects from Within a Plan 36-33
Deleting Objects from Within a Plan 36-33
Sending View Control Messages 36-35
Writing a Plan for Multiple Simulation Objects 36-39
Writing Plans for Remote Entities 36-39
Copying Plans and Plan Statements 36-40
This section explains how to write individual plans. For conceptual information about plans, please see “Introduction to Plans,” on page 34-1, and the previous sections in this chapter.
When you write a plan, keep the following considerations in mind:
If you edit a plan during a simulation, when you apply the changes, the simulation object whose plan has been changed begins executing it from the beginning. This might mean its activities are no longer synchronized with those of the other simula- tion objects, unless the updated plan only includes statements that you want to execute starting at the current point of the simulation. Therefore, we recommend that you edit plans when you first load a scenario, before you start running the simulation.
If you have two or more Plan windows open at the same time, and you open a dialog box, such as Move To, but do not complete the command, you cannot open that same dialog box from another Plan window until you complete the one that is open.
To edit a simulation object’s plan:
Select a simulation object.
Choose Objects Plan, or press p. The Plan window opens. The simulation object’s plan is displayed.
Figure 36-1. Plan window
You can also open the Plan window by clicking the Plan button 
) on the Last Selected Object Panel.
Add new statements, edit statements, or delete statements as described in the following sections.
When you add statements to a plan, you add them after the currently selected state- ment.
Open the Plan window for a simulation object.
In the Plan window, select the statement immediately above where you want to insert a new statement. If the plan does not have any statements yet, the plan root – Plan is already selected.
Choose Task category Task, where category is one of the categories on the Task menu and Task is a task listed for the selected category. A dialog box appropriate to the task opens. The procedures for filling out each type of task dialog box are described in Chapter 26, Assigning Tasks through Chapter 31, Tasks for Aggregate- Level Scenarios.
Complete the required parameter information.
Click OK in the task dialog box to add the statement. You can click Cancel at any time to exit a task dialog box.
To add a set data request to a plan, follow the same procedure as for adding a task, except choose Set category Set Data Request.
The procedures for filling out Set statement dialog boxes are in Chapter 34, Setting the State of Simulation Objects.
Some task and set statements, such as Wait, or Reorganize, do not require you to specify any values. They are added immediately to the plan without any intermediate dialog boxes.
To add an If condition to a plan:
In the Plan window, select the statement immediately above where you want to insert the If block. If the plan does not have any statements yet, the plan root – Plan is already selected.
Choose Conditions If. The If/Else Expression dialog box opens (Figure 36-2).
Optionally, in the Description box, type a description to use in the If statement instead of the condition syntax.
Create the conditional expression as described in “Building Condition Statements,” on page 36-11.
Click OK. An If statement block is added to the plan.
Select the first line in the block (the If statement).
Add the tasks, sets, or other commands that you want to be executed if the condi- tion is true.
Optionally, select the else line and add the commands you want to be executed if the condition is false.
To add a While block to a plan:
Open the Plan window for a simulation object.
In the Plan window, select the statement immediately above where you want to insert the While block. If the plan does not have any statements yet, the plan root
– Plan is already selected.
Choose Conditions While. The While Expression dialog box opens. (It is iden- tical to the If/Else Expression dialog box (Figure 36-2).)
Optionally, in the Description box, type a description to use in the While state- ment instead of the condition syntax.
Create the conditional expression as described in “Building Condition Statements,” on page 36-11.
Click OK. A While statement block is added to the plan.
Select the first line in the block (the While statement).
Add the tasks, sets, or other commands that you want to be executed if the condi- tion is true.
To add a Wait Until statement to a plan:
Open the Plan window for a simulation object.
In the Plan window, select the statement immediately above where you want to insert the Wait Until block. If the plan does not have any statements yet, the plan root – Plan is already selected.
Choose Conditions Wait Until. The Wait Until Expression dialog box opens. (It is identical to the If/Else Expression dialog box (Figure 36-2).)
Optionally, in the Description box, type a description to use in the Wait Until
statement instead of the condition syntax.
Create the conditional expression as described in “Building Condition Statements,” on page 36-11.
Click OK. A Wait Until statement block is added to the plan.
Adding a trigger to a plan is a three-step process. First, you specify the trigger condition. Then you add the commands to be executed to the trigger body. Finally, you register the trigger in the body of the plan.
Choose Conditions Add Trigger. The Edit Trigger Condition dialog box opens (Figure 36-3).
Optionally, in the Trigger Name box, type a name for the trigger. If you specify a name, it is displayed in the Register command when you register the trigger. If you do not specify a name, the text of the condition is displayed in the Register command.
Optionally, select the Automatically Reregister Trigger check box to specify that the trigger should be automatically reregistered after it runs.
Optionally, select the Interrupt Current Task check box to specify that the trigger should interrupt the currently running task rather than suspending and resuming it.
Create the conditional expression as described in “Building Condition Statements,” on page 36-11.
Click OK. If the Trigger Body pane is not already visible, the Plan window expands to show the it (Figure 36-4).
Select the first line in the Trigger pane (Trigger).
Add the tasks, sets, or other commands that you want to be executed when the condition becomes true.
Register the trigger. For details, please see “Registering Triggers,” on page 36-8.
Writing a trigger does not include it in a plan. You must register the trigger.
To register a trigger:
In the Plan window, select the statement below which you want to register the trigger.
Choose Conditions Register Trigger. The Register Trigger dialog box opens (Figure 36-5).
Select the trigger you want to register from the list. (If there are no triggers in the plan, select New.)
Click OK. (If you selected New, the Trigger dialog box opens. Follow the proce- dure for writing a trigger. Then register the trigger.)
By default, once the statements in a trigger get executed, the trigger is unregistered and VR-Forces no longer tests the condition. However there may be cases where you want to test for a recurring condition. You could register the trigger again when the trigger block competes. Or, when you create or edit a trigger, you can specify that it automati- cally reregister. For details. please see “Adding a Trigger to a Plan,” on page 36-7.
As an alternative to using triggers, you can write reactive tasks, which work similarly to triggers or you can write a regular scripted task that is designed to repeatedly test a condition.
You can unregister triggers from within a plan. Unregistering a trigger does not remove it from a plan. It causes VR-Forces to stop testing the condition. You might want to unregister a trigger in response to a change in scenario circumstances that makes the actions in the trigger undesirable.
To unregister a trigger:
Select the plan statement above where you want to add an Unregister Trigger state- ment.
In the Plan window, choose Conditions Unregister Trigger. The Unregister Trigger dialog box opens.
Select the trigger that you want to unregister.
Click OK.
If you add triggers to a plan and then decide not to use (register) them, you can quickly remove them from the plan. (However, there is no penalty for leaving unused triggers in a plan.)
To clean up unused triggers, choose Plan Clean Up Unused Triggers.
You can edit simple statements in the Plan window.
To edit a plan statement:
Double-click the statement or select the statement and click the Edit button 
). An edit dialog box for the particular statement type opens.
Enter the changes you want to make.
Click OK in the edit dialog box.
Click OK or Apply in the Plan window.
Writing Plans — Printing Plans
To delete a statement from a plan:
Select the statement you want to delete.
Click the Delete button 
) or press Delete.
To delete all statements in a plan:
Select the top line in the plan.
Click Delete or press Delete.
You can print plans. The printout lists the name of the scenario, the simulation object’s name, and the plan statements.
To print a plan:
Open a global plan or the Plan window for the simulation object whose plan you want to print.
Choose Plan Print. A standard print dialog box for your operating system opens.
Complete the dialog box as you normally would.
You can save changes to a plan and continue editing, or save changes and exit the Plan window. The plan is saved to the scenario plan file. You do not specify a file to save it to.
To save changes to a plan, in the Plan window click Apply or OK.
If you want to add an If block, a While loop, a Wait Until, or a trigger, you must specify a condition to be tested. The conditional expression dialog box is a dynamic dialog box that lets you build a condition. It contains lists that have the permissible options for each step of a condition. As you select options, the dialog box redisplays, adding additional fields. You can build condition statements using comparison opera- tors, logical operators, and tests of simulation object status.
A condition statement can have one condition or many. They can be nested and grouped. In the following sections we explain how to build a simple condition and how to build a complex condition.
Although the If/Else Expression, While Expression, Wait Until Expression, and Trigger dialog boxes differ slightly, the process of building a condition is the same for all of them.
To build a condition statement that has one condition:
On the Conditions menu, choose the type of condition you want to create. The applicable dialog box opens (Figure 36-6). The top line in the condition specifies that all of the conditions are True. Since we are creating a condition statement that just has one condition, this line is largely irrelevant except for the Evaluates To column.
Optionally, in the Description box, type a short summary of the condition.
Optionally, in the Evaluates To list, change the entire condition from True to False.
In the <choose a conditional> list, select the condition that you want to test. If applicable, a dialog box opens for you to specify the parameters of the condition.
Specify the parameters of the condition.
Click OK. The condition is displayed in the display box at the bottom of the dialog box.
Optionally, in the Evaluates To list, change the condition from True to False. Figure 36-7 shows a simple condition.
Click OK. The condition statement is added to the plan or the Trigger pane. In Figure 36-8, note that the If statement uses the text from the description (in Figure 36-7) instead of the full syntax of the condition shown at the bottom of the If/Else Expression dialog box.
Figure 36-8. Simple conditional expression in a plan
You can build condition statements with multiple conditions, nested conditions, and logical operators. The condition expression dialog box displays the syntax of the condi- tion as you build it. The layout of the window shows which conditions are grouped and which are subordinate to others. For an example, of building a complex condition, please see “Complex Condition Tutorial,” on page 36-15.
To build a complex condition:
On the Conditions menu, choose the type of condition you want to create. The applicable condition expression dialog box opens. The top line in the condition specifies that all of the conditions are True.
Optionally change the top level logical operator to Or.
Optionally change the top level evaluator to False.
In the <choose a conditional> list, select the condition that you want to test. If applicable, a dialog box opens for you to specify the parameters of the condition.
Specify the parameters of the condition.
Click OK. The condition is displayed in the display box at the bottom of the dialog box.
Click the Add button ( ) next to the top line of the condition. A new condition line is added.
Select a condition to test and specify its parameters.
Continue to add conditions as desired. The condition syntax updates as you add conditions.
Optionally, select a new logical operator in the conditions list (And or Or). A subordinate condition line is added under the logical operator and indented.
Add conditions for the logical operator group as you did for the top level logical operator. To simplify the view, you can expand and collapse the logical grouping by clicking the arrow to the left of the logical operator line.
Continue adding conditions as desired.
Click OK.
This section walks you through the process of creating a complex condition. It creates the following conditional expression:
If(“M1A2 4" in area "Area 1" AND ("M1A2 2" left of "Phase Line 1" OR Entity "T80 1" destroyed))then
else endif
The procedure assumes a scenario with four M1A2 entities, a T-80, a phase line, and an area.
To build the condition statement:
Open the Plan window for M1A2 1.
Choose Conditions If. The If/Else Expression dialog box opens (Figure 36-9).
Type a description for the expression you want to build (Figure 36-10).
In the <choose a conditional> list, select Entity in Area. The Entity in Area dialog box opens.
In the Entity in Area dialog box, select M1A2 4 and Area 1.
Click OK. The condition is added and the If expression is updated (Figure 36-11).
Figure 36-11. Entity in Area condition added
On the All of the conditions line, click the Add button ( ). A new line is added to the window (Figure 36-12).
In the <choose a conditional> list, select Any of the conditions (Or). A new line is added to the window (Figure 36-13).
In the <choose a conditional> list, select Entity Left of Phase Line. The Entity Left of Phase Line dialog box opens.
Select M1A2 2 and Phase Line 1.
Click OK. The condition is added and the If expression is updated (Figure 36-14).
On the Any of the conditions (Or) line, click the Add button. A new line is added to the window (Figure 36-15).
In the <choose a conditional> list, select Entity Destroyed. The Entity Destroyed dialog box opens.
Select T80 1.
Click OK. The condition is added and the If expression is updated (Figure 36-16).
In the If/Else Expression dialog box, click OK. The If expression is added to the plan window. Notice that the expression uses the text from the Description box (Figure 36-17).
If you did not include a description, the entire syntax of the expression is displayed (Figure 36-18).
Figure 36-18. If expression using expression syntax
To edit an If, While, or Wait Until condition statement:
In the Plan window, double click the statement. The applicable expression building dialog box opens.
To edit the parameters of a condition, click the Edit button ( ) for that condition and change the parameters as desired.
To change the condition being tested, select a different condition in the list and specify its parameters.
To delete a condition, click the Delete button ( ) for that condition.
To change how the condition is evaluated, choose a different option in the Evalu- ates To list.
Click OK.
To edit a Trigger:
If the Trigger pane is not displayed, click the Expand button 
) to show it.
In the Triggers list, select the trigger that you want to edit.
Click the Edit button ( ). The Trigger dialog box opens.
To edit the parameters of a condition, click the Edit button ( 
) for that condition and change the parameters as desired.
To change the condition being tested, select a different condition in the list and specify its parameters.
To delete a condition, click the Delete button ( ) for that condition.
To change how the condition is evaluated, choose a different option in the Evalu- ates To list.
Click OK.
A specific named simulation object, for example, simulation object M1A2 1 is in Area 1.
An enumeration, for example, any simulation object with enumeration 1:1:225:1:1:3:0 (any M1A2).
That for units, the entire unit must satisfy the condition (the default), or that any subordinate member of a unit satisfies the condition. For example, the default behavior when Entity Is Destroyed is applied to a unit is that all members of the unit must be destroyed for the condition to be true. The alternative is that the condition is true if any member of the unit is destroyed.
The Name and Pattern specifications are mutually exclusive. You cannot specify a name and a pattern. The tab in the Condition dialog box that is visible when you click OK is the specification that gets applied.
To specify a named simulation object in a condition statement:
In a condition dialog box, select the Name tab (Figure 36-19).
Do one of the following:
To specify the simulation object whose plan this is as the simulation object in the condition, select the Use SELF check box.
If you select a unit in the list, the Any Subordinate of Selected Unit check box is enabled. If you want the condition to be satisfied when any member of the unit meets the condition, select the check box.
Click OK.
The enumerations used in the lists on the Pattern tab are loaded from the file
./appData/settings/vrfGui/condition-entity-types.csv. They represent a subset of the enumerations typically used for simulation objects in simulations. However, you can enter any numeric value you want in the enumeration value box.
If you expect that you will consistently need to specify enumeration values that are not part of condition-entity-types.csv, such as a particular country code, you can edit it to add the patterns you need.
To specify a pattern in a condition statement:
In a conditional statement dialog box, select the Pattern tab (Figure 36-20).
Optionally, specify a force to test for.
For each element of the enumeration, select an option from the list, or type an enumeration in the text box.
If the enumeration you enter is for a unit, the Any Subordinate Of Selected Unit check box is enabled. If you want the condition to be satisfied when any member of the unit meets the condition, select the check box.
To specify the inverse of the name, that is, any member except the selected one, select the Invert Pattern check box.
Click OK.
Writing Plans — Using Plan Variables
You can use plan variables in most places where you would select a specific simulation object in a task, set, or conditional test. Plan variables use the names Simulation Object and Created Object. You cannot add your own variables or change the names.
The variables get assigned values only after an object has been created from within a plan (Created Object) or a conditional test has been met that identifies a simulation object (Simulation Object). If you use a variable in a plan that does not have a value, it is ignored.
A Simulation Object variable does not get assigned a value until a condition has been completely evaluated. Therefore, you cannot do something like If Entity In Area AND Simulation Object is Destroyed and expect that the Simulation Object variable refers to the entity identified by Entity in Area. In this case, the Simulation Object variable would refer to a previously identified simulation object or it would just be empty.
Remember that the values assigned to plan variables can change as a simulation object progresses through its plan.
For conceptual information about plan variables, please see “Plan Variables,” on page 35-15.
To use a plan variable in plan statement:
In the statement creation dialog box, select Plan Variables in the Filter list. The dialog box lists Created Object and Simulation Object (Figure 36-21).
Select the variable that you want to use.
Complete the rest of the dialog box normally.
Global plans are not tied to a specific simulation object. However, since they must be executed by a simulation engine, they are assigned to a specific back-end.
Global plans have a limited set of Task and Set commands and the same set of Commands menu options and conditions as individual plans. (You can add additional tasks using the VR-Forces API or by writing scripted tasks.) You can open an Informa- tion dialog box for a global plan to see its task status and console messages.
To create a global plan:
Choose Simulation Global Plans. The Global Plans window opens (Figure
36-22). It lists each global plan and the simulation engine on which it is executed.
Click New. The New Global Plan Information dialog box opens.
In the Plan Name box, type a name for the plan.
If your scenario has more than one back-end, select the back-end on which you want to run the global plan.
Click OK. The Global Plan window opens (Figure 36-23).
Writing Plans — Creating Global Plans
Add commands from the Task, Set, or Conditions menu, as described in “Adding a Task or Set Data Request to a Plan,” on page 36-4 and “Adding an If Block to a Plan,” on page 36-5. Add commands from the Commands menu as described in “Adding Commands to a Plan,” on page 36-29.
Optionally, select the Quick Launch check box to enable quick launching of this plan. For information about using the Quick Launch Toolbar, please see “Controlling When Global Plans Run (Quick Launch),” on page 36-28.
Optionally, select the Show on Quick Launch Toolbar check box to add this global plan to the Quick Launch toolbar.
Optionally, in the Ordinal box, specify the position of this plan on the Quick Launch toolbar.
Optionally, change the icon for this plan on the Quick Launch toolbar, as follows:
Click the Browse button next to the icon name. A file chooser window opens.
Select the file you want to use for the icon.
Click Open.
Click OK.
If you enable quick launch for a global plan, it does not start executing until you launch it. You can launch it from the Quick Launch toolbar, from the Global Plans window, or from another plan. (You can enable quick launch without putting an icon on the Quick Launch toolbar.) When you launch a global plan, it runs to the end. When it finishes, you can launch it again.
When the Quick Launch toolbar is docked, it shows an icon for each quick launch item. To find out what the icon represents, mouse over it and read its tooltip. If you undock the toolbar, it displays the name for each quick launch item.
To launch a global plan from the Quick Launch toolbar, click its icon.
To launch a global plan from the Global Plans window:
Choose Simulation Global Plans. The Global Plans window opens (Figure 36-22).
Select the global plan you want to launch. If it is not running, the Launch button becomes active.
Click Launch. The global plan runs. When it completes, the Launch button becomes active again.
To launch a global plan from a plan:
Open the plan window for an individual plan or a global plan.
Choose Commands Launch Global Plan. The Launch Global Plan window opens.
Select the global plan you want to launch.
Click OK.
To open an Information dialog box for a global plan:
Choose Simulation Global Plans. The Global Plans window opens (Figure 36-22).
Select the global plan for which you want to open an Information dialog box.
Click Information.
The Commands menu lets you assign tasks and set data requests to simulation objects and create the objects on the Simulation Objects Palette, Tactical Graphics Palette, and Hazards/Obstacles Palette. There are also several commands that are only available on the Commands menu. Except as noted in this section, the procedures for adding global commands and conditional statements to a global plan are the same as the procedures for adding them to individual plans.
Since a global plan has no idea what type of simulation object you might want to give a task or set data request to, when you add a task or set, the full list of possible tasks and sets is available. There is no context sensitivity like there is when you select a simulation object and view the Task or Set menu. It is up to you to be sure that the task or set you are assigning to a simulation object is supported by that object.
The best way to determine this is to create a simulation object of the type to which you want to give a task and see if the task or set data request is available on its context-sensitive Task or Set menu. You can also check Appendix D, Systems and System Usage to see if a simulation object type has the system used for a particular task.
The commands on the Task and Set menus in an individual plan apply implicitly to the simulation object for whom you are writing a plan. Tasks and sets on the Commands menu must be assigned explicitly to a target simulation object.
Other than the requirement to specify the target simulation object, adding a global task or set command to a plan uses the same procedure as adding any task or set to an indi- vidual plan.
To assign a task from the Commands menu:
In a Plan window or Global Plan window, choose Commands Task. The Task dialog box opens (Figure 36-24).
The procedure for adding a set data request is the same as for a task, except that you choose Commands Set and the Set dialog box opens.
In the Apply Command To group box, select a simulation object from the list or type its name in the Name box. The simulation object does not have to exist in the scenario at the time you add the command, but you should be sure that it will be created before the command is run. The window displays a list of tasks for the selected simulation object (Figure 36-25). If the simulation object already exists in the scenario, the list of tasks is context-sensitive.
Remember that a command task affects a simulation object like an independent task. It interrupts the current task and causes the simulation object to abandon its plan. If you are adding a command to an individual plan, be sure that you are assigning it to some other simulation object and not the simulation object for whom you are writing the plan. (Unless you want the simulation object to abandon its plan.)
Select the task you want to assign.
Click OK. If the task takes parameters, a dialog box opens.
If the task does not take parameters, such as Wait, the command is added to the plan.
If the task takes parameters, specify the parameters and click OK in the task- specific dialog box. Please see Chapter 26, Assigning Tasks through Chapter 31, Tasks for Aggregate-Level Scenarios and Chapter 34, Setting the State of Simulation Objects for the details of assigning specific tasks and sets.
Click OK. The command is added to the plan.
If you want to edit a task or set command in a plan, you can:
Delete the plan statement and start over.
Edit the existing statement. If you edit the existing statement, you can:
Delete the current task and choose a different one.
Edit the parameters of the task.
To edit a task or set command in a plan:
Select the plan statement you want to edit.
Click the Edit button, or double-click the statement. The Send Task or Send Set dialog box opens. The task list is grayed out. If you are not sure of the task that you are editing, you can read the text of the command below the window (Figure
36-26).
Figure 36-26. Send Radio Task dialog box for plan command
To clear the task and start over, click the Delete button ( ).
To keep the same task and change the parameters, click the Edit button ( ). The appropriate dialog box opens and you can edit the parameters.
Click OK.
You can send messages to be displayed in the console on an object’s Information dialog box and to the back-end console. Messages sent by global plans go to the back-end console. Messages sent from a simulation object’s plan go to the console in its Informa- tion dialog box.
If the notification level for a console message is lower than the notification level config- ured for the back-end or the target simulation object, the message is not displayed. For example, if a simulation object’s notification level is set to Info, it receives Error, Warn, and Info messages, but not messages set to Verbose or Debug.
To send a console message from a plan:
In a plan window, choose Commands Console Message. The Console Message dialog box opens.
Select the notify level from the list.
Type the message you want to send.
Click OK.
You can create any of the objects on the Simulation Objects, Tactical Graphics, and Hazards/Obstacles palettes from within a plan.
To create an object from a plan:
In a plan window, choose Commands Create palette, where palette is one of the object creation palettes. The selected palette opens.
Select the object you want to create.
Create the desired object as you would if you were creating it directly from one of the object creation palettes. When you are finished creating the object, a Create command is added to the plan and the object itself disappears. (The object disap- pears because you are not actually creating the object right now, you are just creating the command that will create it when the plan executes.)
You can delete any object in a scenario from a plan.
To delete an object from a plan:
In a plan window, choose Commands Delete Object. The Delete Object dialog box opens.
Type the name of the object you want to delete or select the object in the list or on the terrain.
Click OK.
The Delete Object global command lets you delete any specified object. If you just want to delete the simulation object whose plan you are editing, you can use the Delete Self command. Like the Use Self option in some conditions, Delete Self provides a non- entity-specific command that is useful for plans that you want to assign to multiple simulation objects.
To assign the Delete Self command, choose Commands Delete Self.
The Issue Plan global command lets you assign a plan to a simulation object. When you issue a plan, the new plan replaces whatever plan or task the simulation object is executing. Although you can issue a plan to any simulation object, this command is particularly useful when you create a simulation object after a scenario has started.
When you create a scenario, you cannot create a plan for a simulation object that does not exist. Therefore, if you create a simulation object after the scenario starts (using the Create global command), it is difficult to send it a sequence of tasks because global commands are not executed in sequence (as discussed in “Introduction to Individual Plans and Global Plans,” on page 35-2). The Issue Plan command solves this problem.
Issue Plan is a concurrent task. Including it in a plan does not affect the current task that the simulation object is executing or the sequencing of tasks in its plan.
To issue a plan to a simulation object:
In a plan window, choose Commands Issue Plan. The Issue Plan dialog box opens (Figure 36-27).
Figure 36-27. Issue Plan dialog box
In the Apply command To: group box, select the simulation object to which you want to assign this plan or type the name of the simulation object in the Name text box. If this is a simulation object that does not yet exist (because you plan to create it after the scenario starts), you must type the name and you are responsible for ensuring that the name you type matches the name of the simulation object that gets created.
Use the right side of the dialog box to write a plan. It has the exact same set of menus and commands as the Plan dialog box. Follow the procedures described else- where in this chapter to write the plan.
Click OK.
The Observer View command works only with VR-Forces. It does not affect other VR- Vantage applications. If you send the Observer View command, you can specify a tran- sition time to the new view, similar to the automated transition described in “Animating Transitions Between Observer Views,” on page 49-32.
The View Control command does not support all of the view modes. However, you can create a saved view using any view mode and send the saved view.
If you send an observer view, the current values for the observer view are put into the plan. If you subsequently change the observer view, the changed values do not get picked up.
To send a view control message:
In a plan window, choose Commands Send View Control. The Send View Control window opens (Figure 36-28).
Select an Observers to Control option. Observer 1 sends the view control command to Observer 1 in all VR-Vantage applications. If you want to direct the view control message to a particular observer:
Select Specific. The dialog box expands to show a list of observers.
Select the observers you want to control by object name (such as 1:3101 Observer 1) or by observer name (such as Observer 2).
Click OK.
In the View Action list, select the view control you want to send, as follows:
Reset. Reset the observer view to the default view.
Detach. Detach the observer from an attached simulation object.
Observer View. Sends the selected observer view (from the Observer Views Panel).
Attach mode, where Attach mode is Absolute or one of the attach modes. Sends the selected attach mode.
For every command except Reset and Detach, the dialog box redisplays to add a selection window appropriate to the view mode.
If you selected Observer View as the View Action, select the observer view that you want to send (Figure 36-29). Optionally, specify a transition time, in seconds.
If you selected Absolute mode or an attach mode as the View Action, complete the dialog box (Figure 36-30) as follows:
In the Observer Mode list, select the observer mode for the view control message.
If you selected Absolute mode, specify the location of the observer and, option- ally, an offset orientation.
If you selected an attach mode, select the simulation object to attach to.
If you selected an attach mode that supports an offset vector or offset orienta- tion, optionally select Manual and specify an offset. The default offset is 0,0,0.
If you select Track, specify the location for the observer to track from.
If you select Tether Track, select a secondary simulation object and, optionally, a position offset.
Click OK.
Writing Plans — Writing Plans for Remote Entities
To write a plan for a unit:
Select the unit.
Follow the procedures for writing a plan for an individual simulation object.
Please see “Independently Tasking Unit Members,” on page 26-12 for notes about how simulation objects that are members of units respond to individual plans and independent tasks.
You can write a plan and assign it to multiple simulation objects at the same time. If any of the simulation objects already has a plan, it is overwritten by the new plan. After you assign a plan using this procedure, you can subsequently edit the plans for partic- ular simulation objects and the changes do not affect the other simulation objects.
If you select several simulation objects and they all have the exact same plan, the plan window displays that plan. If any of the simulation objects have different plans, you are given the option to continue or cancel. If you continue, VR-Forces displays an empty Plan window and the new plan replaces whatever plans the simulation objects previously had.
To write a plan for multiple simulation objects:
Select the simulation objects to which you want to assign the same plan.
Choose Objects Plan. The Plan window opens.
Add statements to the plan as you would if you were writing a plan for an indi- vidual simulation object.
Click OK. The plan is assigned to the selected simulation objects.
If you attach components to remote entities, you can write plans for those entities. To assign plans, the entities must exist in the exercise, must have attached components, and must be present in the exercise when VR-Forces saves the scenario. The plans must be appropriate for the attached components. Movement tasks are not appropriate, because VR-Forces cannot control the location of a remote simulation object. Appro- priate plan statements might be to enable spot reporting, or to send a radio message. For details about how to attach components to remote entities, please see “Attaching VR-Forces Components to Remote Entities,” on page 76-2.
Writing Plans — Copying Plans and Plan Statements
You can copy plans and individual plan statements and paste them elsewhere in a plan or into another simulation object’s plan.
To copy plans and plan statements:
Open the Plan window for the plan that you want to copy.
To copy the entire plan, select the top line in the plan (Plan). To copy a statement, select the statement. If you select a conditional statement, the entire statement block is selected.
Choose Plan Copy Plan or click the Copy button 
).
Open the Plan window for the simulation object you want to copy the plan to.
Select the line just above where you want to insert the copied plan.
Click the Paste button 
).
Continue editing the plan.
Save the plan.
Writing Plans — Restarting a Plan
There may be occasions when you want to restart a simulation object’s plan without restarting a scenario. You can restart a plan interactively or by placing a Restart Plan command in a plan.
When you restart a plan, VR-Forces processes the statements in the plan, starting from the first statement. However, the simulation object executes tasks starting from its current location, not the location it had at the start of the scenario (unless it has not moved since the start of the scenario).
To restart a plan interactively:
Select the simulation object whose plan you want to restart.
Choose Objects Restart Plan. To restart a plan from within a plan:
Open a simulation object’s plan or a global plan.
Choose Commands Restart Plan. The Restart Plan dialog box opens.
Select the simulation object whose plan you want to restart.
Click OK.
Save the plan.
To restart a plan from the Plan window:
Open a simulation object’s plan.
Click Restart.
Writing Plans — Abandoning a Plan
The simulation object stops whatever task it is working on, even if it is an indepen- dent task.
The plan is marked as complete.
All registered triggers are deleted.
The statement indicator skips to the end of the plan.
The simulation object enters a wait state.
If you give a simulation object that is executing a plan an independent task, VR-Forces prompts you before it abandons the plan. (There is no prompt for the Abandon Plan command.) You can disable the prompt. For details, please see “Enabling and Disabling the Task Confirmation Prompt,” on page 26-6.
You can abandon a plan interactively or by sending an Abandon Plan command in an individual or global plan.
To abandon a plan interactively:
Select the simulation object whose plan you want to abandon.
Choose Objects Abandon Plan. To abandon a plan from within a plan:
Choose Commands Abandon Plan. The Abandon Plan dialog box opens.
Select the simulation object whose plan you want to abandon.
Click OK.
Save the plan.
To abandon a plan from the Plan window:
Open a simulation object’s plan.
Click Abandon.
Tactical graphics are objects that represent points, lines, areas, and information overlaid on the terrain. This section describes overlays and particular details about tactical graphics. For generic information about creating tactical graphics, please see Chapter 16, Creating and Placing Objects. For information about combat engineering objects, which are displayed similarly to tactical graphics, please see “Combat Engineering Objects,” on page 23-9.
VR-Forces Users Guide
Section VII - Tactical Graphics
VII-1
Tactical Graphics
Section VII - Tactical Graphics
VII-2 VT MAK
37. Introduction to Tactical Graphics
This chapter is a brief introduction to tactical graphics.
Displaying Tactical Graphics 37-6
Showing and Hiding Tactical Graphics 37-8
Showing and Hiding Tactical Graphics Labels 37-9
Displaying Height-Above-Terrain Lines for Vertices 37-10
Introduction to Tactical Graphics — Introduction
VR-Forces lets you add tactical graphics to scenarios. Tactical graphics are objects that represent points, lines, areas, and information overlaid on the terrain. They are auto- matically assigned to overlays. (You can configure the default overlay assignments and can change the overlay at or after creation.) Simulation objects have knowledge of some types of tactical graphics, which allows tasks and plans to take them into account. VR- Forces supports the following types of tactical graphics:
Waypoint. A specific X, Y, Z coordinate.
Phase line. Infinitely long line defined by two points.
Route. A sequence of points in three-dimensional space.
Pedestrian path. When humans plan paths in navigation areas that have naviga- tion data, if a pedestrian path is present that can take them to their destination, they will use it. You can think of a pedestrian path as a route that a human will automatically choose to follow instead of being told to follow it. Pedestrian paths are supported only for entity-level scenarios.
Disaggregation area. An area in which an aggregated unit automatically disaggre- gates if automatic disaggregation is enabled.
Terrain Page-in Area. An area in which streaming or paged terrain is given priority for paging in.
In entity-level scenarios, waypoints, lines, routes, and areas are in the control objects category on the Tactical Graphics palette. Obstacles, linear obstacles, and pedestrian paths are on the Hazards/Obstacles palette.
In aggregate-level scenarios, waypoints, lines, routes, area, and obstacles are on the Tactical Graphics palette. Linear obstacles and pedestrian paths are not supported.
Terrain Profile Line. A line that lets you examine the profile of the terrain along the line.
Intervisibility Line. A line that shows line-of-sight between two points.
Introduction to Tactical Graphics — Introduction
Lines. Generic lines and lines with particular graphics, such as main axis and forti- fied line. Simulation objects treat most lines as routes.
Points. Various military symbology, such as point of contact and decision point. Simulation objects treat most points as waypoints.
Areas. Minefields and other areal objects. These are not treated like area control objects.
Text.
Symbols. Symbols that do not represent simulated objects. They are just graphics on the screen and do not affect the simulation.
Circles, ellipses, and boxes. These are just graphics and do not affect the simula- tion.
Volumetric objects. Volumetric areas, circles, boxes, ellipses, and corridors allow you to test for a simulation object’s presence in a 3D volume rather than just a 2D area. They are useful for defining air corridors and airspace.
Combat engineering objects. Combat engineering objects are lines and areas that can impede the progress of simulation objects and cause damage to them. Combat engineering objects are supported only in aggregate-level scenarios. For informa- tion about how they work, please see “Combat Engineering Objects,” on
Tactical graphics have names. New objects are assigned default names in the format Point 1, Point 2, Route 1, Route 2, and so on. You can specify an alternative name when you create the object. A graphical object’s name can be up to 255 characters long.
Tactical graphics can have labels and extended labels. They do not have to be unique and do not have a length restriction.
Tactical graphics are assigned to a force. Waypoints are displayed using their force color. To determine the force of other tactical graphics, examine the Force attribute in the Environmental State page of the graphic’s Information dialog box. For more informa- tion, please see “Displaying Information About an Object,” on page 18-3.
The following sections provide more information about the basic control objects. For information about the other tactical graphics types mentioned in this section, please see:
Chapter 46, Intervisibility.
Chapter 16, Creating and Placing Objects.
Chapter 38, Overlays.
Introduction to Tactical Graphics — Points
A point identifies an X, Y, Z coordinate in the terrain. You can command a simulation object to travel to a point and to travel back and forth between points. Figure 37-1 illustrates waypoints in the 3D and 2D views. In 3D, the bottom of the symbol points to the location of the waypoint. In 2D, it is centered. You can place several different kinds of points on overlays.
A point can have an altitude value. This allows you to send aircraft to waypoints or have them patrol between points.
Location of waypoint
3D 2D
A phase line is defined by two points, but is considered to extend indefinitely in either direction and have infinite height. A phase line is used to test the location of a simula- tion object, for example: Is simulation object A to the left of phase line B? The left side of the line is determined relative to the direction in which the line is drawn. A phase line’s label is placed at the beginning of the line. Therefore, you can always determine which side of a line is the left side. Figure 37-2 illustrates two phase lines. The arrows are placed to the left of the line and indicate the direction of the line.
Simulation objects cannot move along phase lines, so do not create a phase line if you want a two point route.
Phase Line 1
Phase Line 2
Figure 37-2. Phase line direction
Introduction to Tactical Graphics — Obstacles
Simulation objects can move along routes from one end to the other, and can patrol back and forth along them.
Do not create a two-point route if you want a phase line. VR-Forces cannot determine whether a simulation object is to the left or right of a route.
Many “line” tactical graphics are treated as routes by simulation objects.
In addition to obstacles, aggregate-level scenarios support combat engineering objects and contamination areas. These objects can defend, damage, or impede simulation objects.
Obstacles and linear obstacles are on the Hazards/Obstacles palette in entity-level scenarios. Obstacles (areal) are on the Tactical Graphics palette in aggregate-level scenarios. (The many combat engineering objects available in aggregate-level scenarios make simple obstacles comparatively less useful.) Linear obstacles are not supported in aggregate-level scenarios. They only work in navigation areas.
You can configure the display of tactical graphics as follows:
Enable and disable the display of tactical graphics.
Show or hide vertex indicators for point, linear, and areal objects.
Show or hide height-above-terrain lines.
Display height-above-terrain lines only for selected graphics.
Vertex indicator HAT line Height Route
Figure 37-3. Tactical graphics with height-above-terrain lines (3D)
Figure 37-4. Tactical graphic (2D)
To show or hide tactical graphics:
Choose Settings Display. The Display Settings dialog box opens.
Select the Tactical Graphics Display Settings page (Figure 37-5).
Select or clear the Show Tactical Graphics check box.
To show only active tactical graphics, select Show Only Active Tactical Graphics. For more information about active tactical graphics, please see “Active and Inactive Tactical Graphics,” on page 39-19.
You can also enable and disable tactical graphics by choosing Settings Tactical Graphics or clicking the Tactical Graphics button ( ) on the Display Settings Toolbar.
On the Overlays tab, you can show and hide tactical graphics individually and by overlay.
To control the display of tactical graphics from the Overlays tab:
On the Objects List Panel, select the Overlays tab (Figure 38-2).
To hide all graphics on a particular overlay, clear the check box for that overlay.
To hide a specific tactical graphic, clear its check box.
To redisplay a hidden tactical graphic or overlay, select its check box.
In addition to displaying the outlines of tactical graphics, you can display graphics (labels) for the vertices of these objects. Vertex labels are enabled in Figure 37-3 and Figure 37-4. In Plan View mode, VR-Forces also displays a tactical graphic’s name, label, and extended labels, if any. For details about displaying labels for 2D icons, please see “Displaying Labels for 2D Icons,” on page 18-14.
i Displaying vertex labels can affect performance.
To show or hide vertex labels:
Choose Settings Display. The Display Settings dialog box opens.
Select the Tactical Graphics Display Settings page (Figure 37-5).
Select or clear the Show Tactical Graphics Labels check box.
You can also enable and disable tactical graphics labels by choosing Settings
Tactical Graphics Labels or clicking the Tactical Graphics Labels button 
) on the Display Settings Toolbar.
In 3D observer modes, you can display height-above-terrain (HAT) lines for the vertices of tactical graphics (Figure 37-3). These vertical lines between an object’s vertices and the ground help you understand the relationship of the object to the terrain. The height for each vertex is displayed (using whatever units are configured on the Display Units Settings page).
HAT lines are shown only for tactical graphics that could be above or below the ground, such as routes, and waypoints. You can show and hide these lines and you can specify that they be shown for all objects or only for the selected objects.
! Use of height above terrain lines can reduce the frame rate.
To show or hide height-above-terrain lines:
Choose Settings Display. The Display Settings dialog box opens.
Select the Tactical Graphics Display Settings page (Figure 37-5).
To display HAT lines, select the Enable Height Above Terrain Lines check box.
To only display lines for selected objects, select the Only Display Height Above Terrain Lines For Selected Tactical Graphics check box.
This chapter explains how to create and edit overlays.
Creating and Editing Overlays 38-2
Hiding the Objects on an Overlay 38-4
Changing an Overlay’s Name 38-4
Saving and Loading Tactical Graphics and Overlays 38-5
Loading Tactical Graphics and Overlays 38-5
Exporting Tactical Graphics as Shapefiles 38-6
Importing Shapefiles into Overlays 38-7
Overlays allow you to add graphic objects to the VR-Forces window as if you were adding clear plastic overlays to a physical map and drawing on them. They provide a convenient way to organize and manage the tactical graphics and simulation objects in a simulation. You can add any number of overlays. You can rename them. You can enable or disable editing of the objects they contain.
When you create an object, if you do not explicitly assign it to an overlay, it gets placed on a default overlay. If the default overlay does not exist, it gets created. The default overlay for an object type is configured in the Simulation Object Editor.
Figure 38-1. Overlays tab and Overlay Bar
Overlays — Creating and Editing Overlays
To create an overlay:
On the Objects List Panel, select the Overlays tab (Figure 38-2).
Click the Add button ( ). An overlay is added to the list with a default name.
Optionally, change the name as described in “Changing an Overlay’s Name,” on page 38-4.
To select an overlay, click its name on the Overlays tab.
When an overlay is locked, you cannot edit the objects on it. You can still add and delete objects.
To lock or unlock an overlay:
On the Objects List Panel, select the Overlays tab.
Select the overlay you want to lock or unlock.
Click the Lock/Unlock button ( 
), or double-click the entry in the Locked column. It will toggle between Yes and No.
You can hide the objects on an overlay. This may be convenient if you want to focus on a particular set of simulation objects or tactical graphics while you are editing or observing a scenario. You can hide all of the objects on an overlay or individual objects.
To hide all of the objects on an overlay, do one of the following:
Click the overlay’s tab on the Overlay Bar.
On the Objects List Panel, Overlay tab, clear the check box for the overlay that you want to hide.
To hide individual objects on an overlay, on the Objects List Panel, Overlay tab, clear the check box for the object.
To hide an overlay by default, place an asterisk(*) at the start of the name, for example, *Tactical Graphics.
You can change the name of a default overlay, such as Entities or Tactical Graphics. However, the next time you create an object that gets assigned to a default overlay, unless you assign it to the renamed overlay, a new overlay with the default name gets created.
On the Objects List Panel, select the Overlays tab.
Select the overlay that you want to rename and click the Rename button ( ), or double-click the overlay whose name you want to change. The name becomes edit- able.
Type a new name.
Press Enter.
Overlays — Saving and Loading Tactical Graphics and Overlays
To delete an overlay:
On the Objects List Panel, select the Overlays tab.
Select the overlay you want to delete.
!
!
When you delete an overlay, all of the simulation objects and tactical graphics on it are also deleted.
Click the Delete button ( ).
If you publish a tactical graphic, it is automatically saved to the order of battle file (.oob). If you do not publish a tactical graphic, it is automatically saved to the overlay file (.ovl). There may be cases where you want to create a set of overlays for use in multiple scenarios. You can save them to an overlay file independently of the scenario, or even save the overlays and not save the scenario at all.
i When you save overlay objects, only unpublished tactical graphics get saved.
To save overlays and tactical graphics:
Choose File Save Overlay. The Save Overlay dialog box opens.
Type a name for the overlay file.
Click Save.
You can load overlays that you have saved from a previous session.
To load overlays:
1. Choose File Load Overlay. The Load Overlay dialog box opens.
2. Select the overlay file you want to load.
3. Click Open.
!
!
When you load overlay objects, you must use the same terrain database you created them on, or a terrain database that includes the area they were created in.
You can export point, line, and area tactical graphics to shapefiles. VR-Forces exports all of the graphics on a selected overlay. This may be useful if you need feature data for a terrain, such as a road network, but there is no feature data available from external sources. You can edit the shapefile created by VR-Forces in an appropriate third-party application to add the attributes needed to fully specify the features. For example, suppose you need a road network. You would create routes in the proper locations in VR-Forces and export the overlay to a shapefile. Then you would edit the shapefile to connect the road segments, specify road width, number of lanes, and so on. You could then load the shapefile in VR-Forces or any other application that supports shapefiles.
When VR-Forces creates shapefiles from tactical graphics, it creates separate files for points, lines, and areas. It appends P.shp, L.shp, or A.shp to the filename you provide based on the tactical graphics types being exported. For example, if an overlay has points and lines and you export them to myFeatures, VR-Forces creates files called myFeaturesP.shp and myFeaturesL.shp.
To export tactical graphics as shapefiles:
On the Objects List Panel select the Overlay tab.
Select the Overlay whose tactical graphics you want to export.
Choose File Save Overlay as Shape Files. The Save Overlay as Shape Files dialog box opens. (You can also right-click an overlay tab and open the context-sensitive menu.)
Type a name for the shapefile.
Click Save.
Overlays — Exporting Tactical Graphics as Shapefiles
You can import feature data into overlays. Features are placed as points, lines, or areas. This is a quick way to create tactical graphics for features such as roads, buildings, and so on. For example, if you were to load the MAK Earth (online).mtf terrain and import BuildingsP.shp, which is used in the Little Pond terrain, it places a group of waypoints at the locations of the buildings. (For more information about BuildingsP.shp, please see “Add a Feature Layer,” on page 63-9.)
Importing shapefiles into an overlay is not the same thing as adding a feature layer to the terrain. For example, importing a file such as RoadsL.shp to an overlay creates routes that can be referenced in movement tasks. Adding it as a feature layer creates a road network that could be used for path planning.
To import feature data into an overlay:
Select an overlay.
Choose File Import Shape File Onto Overlay. The Import Shapefile Onto Overlay dialog box opens.
Select the shapefile you want to import.
Click Open.
39. Creating and Editing Tactical Graphics
This chapter explains how to create and edit overlays and tactical graphics.
Creating Tactical Graphics 39-2
Drawing Circles and Ellipses 39-3
Creating Volumetric Tactical Graphics 39-4
Adding Text to an Overlay 39-5
Assigning Tactical Graphics to an Overlay 39-5
Displaying a Terrain Profile When You Create a Line 39-6
Publishing Tactical Graphics 39-7
Creating a Computed Route 39-7
Creating an Intel Collection Area 39-9
Creating Routes for Aircraft 39-10
Attaching Tactical Graphics to a Simulation Object 39-11
Attaching a Tactical Graphic Automatically 39-11
Deleting Tactical Graphics 39-11
Editing Tactical Graphics 39-12
Resizing Boxes and Text Objects 39-15
Changing the Direction of a Line 39-16
Changing the Color of a Tactical Graphic 39-16
Using the Force Color for Vertices 39-17
Changing Linear and Areal Style Properties 39-17
Active and Inactive Tactical Graphics 39-19
The generic procedures for creating tactical graphics are described in Chapter 16, Creating and Placing Objects. This section provides additional details about tactical graphic creation and placement.
A freehand line is essentially many short line segments. After you create a freehand line you can change the sampling rate used to determine how many segments it has. The fewer the segments, the less fluid the line is.
Unlike other lines, the individual vertices of a freehand line do not have vertex markers. You cannot select them individually on the map. However, you can edit them in the Edit Freehand Line dialog box.
If you reduce the sampling rate, resulting in fewer segments and a less fluid line, once you save the line you cannot automatically increase the number of segments to increase the fluidity of the line. You would have to add vertices by hand.
To create a freehand line:
Click the Tactical Graphics Palette.
Select the Shapes category.
Select Freehand line or Freehand Line with Arrow.
Click where you want the line to start, and while holding down the left mouse button, draw a line on the screen.
Release the mouse button. The Create Freehand dialog box opens.
Edit the properties as desired.
Simulation objects do not interact with circles and ellipses. They are strictly for use as graphics.
To draw a circle:
Click the Tactical Graphics Palette.
Select the Shapes category.
Select Circle. The cursor changes to draw mode and shows a vertex icon.
Click to place the center of the circle. A center point is placed on the terrain and a circle is drawn. There is now a vertex icon on the circumference of the circle.
Drag the mouse to set the radius of the circle.
Click to complete the circle.
To draw an ellipse:
Click the Tactical Graphics Palette.
Select the Shapes category.
Select Ellipse. The cursor changes to draw mode and shows a vertex icon.
Click to set the center of the ellipse. A center point is set and a small circle is displayed with a vertex indicator at the bottom of the circle.
Drag the mouse up or down and click to set the height of the ellipse. A vertex indi- cator is added to the left side of the circle.
Drag the mouse left and right and click to set the width of the ellipse.
Boxes are constrained to be parallelograms. Simulation objects do not interact with boxes. (In other words, they are not areas.)
To draw a box:
Click the Tactical Graphics Palette.
Select the Shapes category.
Select Box. A box is attached to the cursor
Click to place the box in the approximate location that you want.
Double-click any vertex. The vertex changes to show it is editable.
Drag the vertex to reshape the box.
You can create volumetric tactical graphics. Volumetric tactical graphics are useful for defining air corridors, airspace, and similar 3D areas. You can create the following volu- metric graphics:
Area (extruded).
Box (extruded).
Circle (extruded).
Corridor (a linear object).
Ellipse (extruded).
The Entity in Area condition can check to see if an entity is within the volume of an extruded area.
To create a volumetric tactical graphic:
Click the Tactical Graphics Palette.
Select the volumetric tactical graphic you want to create.
Specify the vertices of the tactical graphic just like you would for a 2D tactical graphic. When you right-click to set the final vertex, the Edit dialog box should open.
If the Edit dialog box does not open, click its tab to open it.
If you are creating a route, specify the height and width. If you are creating any other extruded tactical graphic, specify the floor and ceiling (above mean sea level).
Click Create.
You can add text to an overlay. The maximum width of the text object is fixed.
To add text to an overlay:
Click the Tactical Graphics Palette.
Select the Shapes category. (Text is also in the Logistics, Intel, and Symbols catego- ries.)
Select Text. The text “Text” is attached to the cursor.
Click to set the bottom center of the text. The Create Text dialog box opens.
Type the text you want in the Text box.
Edit any other properties as desired.
Click Create.
By default, when you create a tactical graphic, it gets assigned to an overlay with the same name as the palette from which it is created. (You can change the default overlay in the Simulation Object Editor.) If no overlay exists, the overlay is created and the graphic is assigned to it. You can assign a tactical graphic to a different overlay when you create it or edit it. To assign a tactical graphic to an overlay when you create it, set this property as described in “Specifying an Object’s Properties Before You Create It (Click to Locate),” on page 16-13. To move a tactical graphic to a different overlay, follow the procedure in “Moving a Tactical Graphic to a Different Overlay,” on
To move a tactical graphic to a different overlay:
Select the tactical graphic you want to move.
Choose Objects Edit. The Edit Object dialog box opens.
If Attach Object to Mouse is selected, clear the check box.
In the Overlay list, select the overlay that you want the tactical graphic to move to.
Click Update.
You can also move a tactical graphic to a different overlay by dragging it to the new overlay on the Overlays tab of the Objects List panel.
You can display a terrain profile window while you create a line. You can configure VR- Forces to automatically display a terrain profile when a line is created (“Configuring Terrain Profiles,” on page 54-3), or you can display the window manually.
To open a terrain profile window while you are creating a line:
Select the tactical graphic that you want to create as described in “Selecting the Object to Create,” on page 16-4. A Create Object tab is added to the window below the Props Palette (Figure 16-4).
Click the Create Object tab. A Create Object dialog box that is appropriate for the object opens (Figure 39-1).
Click to place the first vertex. The Terrain Profile button is activated.
Click Terrain Profile. A terrain profile window opens.
Complete the line. The terrain profile window stays open until you complete the line.
By default, all tactical graphics are published. That is, they are sent out over the network and are visible to other participants in an exercise. You can choose to not publish a tactical graphic. In that case, it is visible only in the front-end on which it was created.
Published tactical graphics get saved to the order of battle file. Unpublished tactical graphics get saved to the overlays file that gets created as part of the scenario. You can also manually save tactical graphics to an overlay file separate from the one stored with the scenario.
To publish or unpublish a tactical graphic:
Select the graphic you want to edit.
Choose Objects Edit. The Edit Object dialog box opens.
To publish the object, select the Publish Object check box. To unpublish it, clear the check box.
VR-Forces can create routes between two points and take into account criteria such as avoiding buildings, using roads, and avoiding water. Unlike the temporary routes that VR-Forces creates for movement tasks, a computed route is a tactical graphic that is saved with the scenario and can be used by any simulation object.
When you create a computed route, you specify rules that VR-Forces should use when creating the route. VR-Forces includes preconfigured rule sets for ships and ground vehicles. You can add additional preconfigured rule sets. You can also add additional rules. The rules and rule sets are configured in ./data/simulationModelSets/<sms>/gui/ computedRouteRulesTypes.xml.
To create a computed route:
Choose Create Computed Route. The Create Computed Route dialog box opens (Figure 39-2).
Optionally, specify a name, label, and overlay.
Select the force for the route.
Click to place the starting point of the route, or enter a value for the Source Loca- tion.
Click to place the end point of the route, or enter a value for the Destination Loca- tion.
Select the type of vehicle from the list. Ground vehicles and ships have a preconfig- ured set of rules. Select Custom to choose a different set of rules.
If you select Custom, select the rules that you want to be enforced for the route. Clear those you do not want to use.
Click Create.
To create an intel collection area:
On the Tactical Graphics Palette, select the Intel category.
Click Intel Collection Area.
Draw an area on the map as you would for any other tactical graphic area.
In the Create Intel Collection Area dialog box (Figure 39-3), click the Add button ( ) next to the Area Modifiers label. The Choose Force dialog box opens.
Select the force for which you want to add a modifier.
Click OK. The force gets listed in the Area Modifiers window.
Double-click the Modifier column to make it editable.
Type the modifier value you want to apply to this force.
Optionally, add additional force entries to the list.
Click Create.
When you create a route for a fixed-wing entity, remember that as an aircraft flies between the vertices of a route, it starts at the altitude of the first vertex and immedi- ately rises or falls to the altitude of the next vertex as shown in the trajectory in Figure 39-4. (It does not change altitude smoothly between the vertices.) If a terrain feature in- between the two vertices is higher than the trajectory followed by the aircraft, the aircraft will fly into the terrain, even though a line between the two vertices would not pass through the terrain. There is no terrain following built into the route following process for fixed-wing entities.
Route
Terrain profile
Trajectory
Figure 39-4. Fixed-wing trajectory between vertices
This caution applies to rotary-wing entities if there are abrupt changes in elevation in the terrain. Rotary-wing entities can follow the terrain, but they only look down, not ahead, so abrupt changes in terrain could cause a crash.
Creating and Editing Tactical Graphics — Deleting Tactical Graphics
You can attach tactical graphics to a simulation object so that they move with it. For example, if you draw a route on an aircraft carrier deck, you want the route to stay attached to the deck as the carrier moves. Another example is to attach a Terrain Page-in Area to an aircraft so that it pages in terrain as the aircraft flies.
You can attach a tactical graphic to an object manually or automatically (3D observer modes only).
To attach a tactical graphic to a simulation object manually:
Create a tactical graphics as you normally would.
Select the tactical graphic.
Choose Objects Attach Object To. The Attach Object To dialog box opens.
Select the simulation object to which you want to attach the tactical graphic.
Click OK.
You can attach a tactical graphic to a 3D model as you create it. (This procedure uses the automatic embarkation capability.)
To attach a tactical graphic to a 3D model when you create it:
Select a 3D observer mode, such as Stealth mode.
Move the observer to view the simulation object on which you want to attach a tactical graphic.
On the Tactical Graphics Palette, select the tactical graphic that you want to create.
Move the cursor over the 3D model you want to attach to until you see a green box.
Click to place the first vertex (or point for point tactical graphics) on the 3D model.
Continue to create the tactical graphic as you normally would. The first point stays anchored to the model.
To delete a graphical object:
Select the tactical graphic you want to delete.
Choose Objects Delete, or press the Delete key.
Add, delete, and edit vertices (“Editing Vertices,” on page 39-13).
Change its name.
Change the altitude reference (“Setting Altitude in the Create Object or Edit Object Dialog Box,” on page 16-15), “Specifying the Altitude for All of the Vertices in a Route,” on page 16-16.
Change the direction of a line (“Changing the Direction of a Line,” on page 39-16).
Edit linear and areal styles:
Change the pen style and width.
Change the line style.
Add or remove arrows.
Change the fill of an area.
(“Changing Linear and Areal Style Properties,” on page 39-17.)
Move it to a different location (“Dragging an Object to a New Location,” on page 16-19).
Move it to a different overlay (“Moving a Tactical Graphic to a Different Overlay,” on page 39-5).
Change the color (“Changing the Color of a Tactical Graphic,” on page 39-16).
Resize boxes and text objects (“Resizing Boxes and Text Objects,” on page 39-15).
i To edit a tactical graphic, its overlay must be unlocked.
You can edit the vertices of routes and areas. You can edit them dynamically or in the Edit Object dialog box.
You can add vertices to a route or area directly on the terrain or in the Edit Object dialog box.
To add a vertex to a tactical graphic dynamically:
Right-click the vertex next to which you want to add a new vertex. A menu is displayed.
Choose Add Point After or Add Point Before. A point is added midway between the selected vertex and the next or previous vertex, based on the command you chose.
Optionally, edit the new point as described in “Editing a Vertex,” on page 39-14.
To add a vertex in the Edit Object dialog box:
Select the tactical graphic you want to edit.
Choose Objects Edit. The Edit Object dialog box opens (Figure 39-5).
If Attach Object to Mouse is selected, clear the check box.
In the list of vertices, select the vertex after which you want to add the new vertex.
Click the Add button ( ). A vertex is added midway between the selected vertex and the next vertex. If you selected the last vertex, a new vertex is added to the end of the route.
Optionally, edit the new point as described in “Editing a Vertex,” on page 39-14.
Click Update.
Figure 39-5. Edit Route dialog box
You can edit a vertex dynamically or in the Edit Object dialog box.
To edit a vertex dynamically:
Double-click the vertex.
Move the mouse to change the vertex’s location.
Use Alt+mouse wheel or Alt+left mouse button+drag to change the altitude.
Click to place the vertex.
To edit a vertex in the Edit Object dialog box:
Select the tactical graphic you want to edit.
Choose Objects Edit. The Edit Object dialog box opens.
If Attach Object to Mouse is selected, clear the check box.
If you are editing a waypoint, click on the terrain to specify a new location or edit the coordinates and altitude in the Edit Waypoint dialog box.
If you are editing a phase line, route, or area, you can:
Double-click the coordinate value you want to change to make it editable.
Type a new value and press Enter or click someplace outside of the value.
Alternatively, you can click on the map to change the coordinates of the selected vertex. To set the altitude, you must edit the value by hand.
Click Update.
You can delete vertices directly or in the Edit Object dialog box.
To delete a vertex directly:
Right-click the vertex you want to delete. A menu is displayed.
Choose Delete Point. The point is deleted. (There is no confirmation prompt.)
To delete a vertex in the Edit Object dialog box:
Select the tactical graphic you want to edit.
Choose Objects Edit. The Edit Object dialog box opens.
If Attach Object to Mouse is selected, clear the check box.
In the list of vertices, select the vertex you want to delete.
Click the Delete button ( ).
Click Update.
You cannot edit the individual vertices of a box or a text object, you can only resize them.
To resize a box or text object, double-click one of its vertices to make it editable and drag it to create the new object size.
To rotate an ellipse:
Select the ellipse.
Choose Objects Edit. The Edit object dialog box opens.
Select the Free Rotate check box.
Click OK.
Double-click one of the points on the ellipse to make it editable and drag it in a circular direction.
All lines have a direction. The direction affects how a simulation object moves along it and the direction that arrows face, if present. If you draw a line and then decide you want to reverse its direction, you can do so.
To change the direction of a line:
Select the line.
Choose Objects Edit. The Edit object dialog box opens.
Click the Reverse Direction button ( ).
Click OK.
You can change the color of a tactical graphic.
To change the color of an tactical graphic:
Select the graphic whose color you want to change.
Choose Objects Edit. The Edit object dialog box opens.
Click the Color button 
). A color picker dialog box opens.
Click a color button or click the Custom Color button to choose a new color from the Color Picker.
Click OK.
You can specify that the vertices of a tactical graphic use the force color. The color is most obvious when the tactical graphic is selected. It is muted when the graphic is not selected.
To use the force color of a tactical graphics for its vertices:
Choose Settings Display. The Display Settings dialog box opens.
Select the Tactical Graphics Display Settings page (Figure 41-2).
Select the Color Vertices With Force Color check box.
Click OK.
Line style. The different types of special lines, such as Main Axis.
Arrow. You can add arrows to the end of a line, at the end and beginning segment, or at the end of each segment of the line. Figure 39-6 illustrates the arrow styles.
First and last segments
End of all segments
Simple 
Linear 
Main 
Simple Reversed
Berm
Last segment
To change a style property:
Select the graphic you want to edit.
Choose Objects Edit. The Edit object dialog box opens.
Click the Edit Style button ( ). The Edit Style dialog box opens (Figure 39-7). It lists the style options that you can edit for this tactical graphic.
Change the properties by selecting options from the appropriate list or typing new values.
Click OK.
Creating and Editing Tactical Graphics — Active and Inactive Tactical Graphics
In order for inactive tactical graphics to be hidden, you must select Show Only Active Environmentals on the Display Settings dialog box, Tactical Graphics Settings page or click the Show Only Active Tactical Graphics button 
)on the Display Settings Toolber.
For details about the Activation set data request, please see “Activation,” on page 40-3 and “Tactical Graphic Active,” on page 35-14.
To set the activation state of a tactical graphic:
Select the tactical graphic you want to edit. (If you are creating a new tactical graphic, open the Create object dialog box and skip to step 3.)
Choose Objects Edit. The Edit object dialog box opens.
Click the Set Activation button 
). The Set Activation dialog box opens (Figure 39-8).
Creating and Editing Tactical Graphics — Active and Inactive Tactical Graphics
Select one of the following options from the Activation State list:
Active. The tactical graphic is visible.
Inactive. The tactical graphic is not visible if Show Only Active Environmentals is selected on the Display Settings dialog box, Tactical Graphics Settings page.
Use Activation Times. The tactical graphic is active during the times specified in the dialog box.
If you selected Active or Inactive, click OK. If you selected Use Activation Times:
Select Use Simulation Time or Use Time of Day.
In the Activate At boxes, specify the time you want the tactical graphic to be visible.
In the Deactivate At boxes, specify the time you want the tactical graphic to be hidden.
Click OK.
40. Setting the State of Tactical Graphics
You can use set data requests to change the state of a tactical graphic.
Set Data Requests for Tactical Graphics 40-2
Setting the State of Tactical Graphics — Set Data Requests for Tactical Graphics
Set data requests for tactical graphics provide an alternative to using Edit dialog boxes to change the state of a graphic. The advantage of using set data requests is that you can make changes to tactical graphics from plans and in scripted tasks or scripted sets. You can also quickly make changes from the Set menu without needing to open an Edit dialog box.
Setting the State of Tactical Graphics — Activation
The Activation set data request lets you activate or deactivate tactical graphics. In most cases, this is strictly a visual effect: activated tactical graphics are visible; inactive tactical graphics are not visible. However, if you set an indirect fire event area to be inactive, the indirect fire event does not start until the area is activated.
For more information, please see “Active and Inactive Tactical Graphics,” on page 39-19 and “Tactical Graphic Active,” on page 35-14.
To activate or deactivate a tactical graphic:
Select the tactical graphic.
Choose Set Disposition Activation. The Activation dialog box opens (Figure 40-1).
Select one of the following options from the Activation State list:
Active. The tactical graphic is visible.
Inactive. The tactical graphic is not visible if Show Only Active Environmentals is selected on the Display Settings dialog box, Tactical Graphics Settings page.
Use Activation Times. The tactical graphic is active during the times specified in the dialog box.
If you selected Active or Inactive, click OK. If you selected Use Activation Times:
Select Use Simulation Time or Use Time of Day.
In the Activate At boxes, specify the time you want the tactical graphic to be visible.
In the Deactivate At boxes, specify the time you want the tactical graphic to be hidden.
Click OK.
Setting the State of Tactical Graphics — Allow Crossing
The Allow Crossing set data request allows human entities to walk across a crosswalk. When human characters plan a path that includes a crosswalk, when they arrive at the crosswalk, if crossing is allowed, they can cross the street. If it is not allowed, they stop and wait.
To set a crosswalk to be enabled or disabled:
Select a crosswalk tactical graphic.
Choose Set Allow Crossing. The Allow Crossing dialog box opens.
Select or clear the Allow Crossing check box.
Click OK.
The Arrowhead Style set data request lets you set the type of arrowhead, location, and width for linear tactical graphics. For a description of arrowhead styles, please see “Changing Linear and Areal Style Properties,” on page 39-17.
To set the arrowhead style:
Select a linear tactical graphic.
Choose Set Appearance Arrowhead Style. The Arrowhead Style dialog box opens.
Select an option from the Arrow Style list.
Select an option from the Arrow Placement list.
Specify the width, in pixels, of the arrow.
Click OK.
The Color set data request lets you change the color of linear and areal tactical graphics.
To set the color of a linear or areal tactical graphic:
Select a tactical graphic.
Choose Set Appearance Color. The Color dialog box opens.
Select the color you want to use for this tactical graphic.
Click OK.
Setting the State of Tactical Graphics — Notify Level
The Fill Style set data request lets you specify the fill for areal tactical graphics. The fill can be horizontal, vertical, or diagonal lines, or various degrees of opacity.
To set the fill style of an areal tactical graphic:
Select a tactical graphic.
Choose Set Appearance Fill Style. The Fill Style dialog box opens.
Select an option from the Fill Style list.
Click OK.
You can change the force of a tactical graphic. For details, please see “Force,” on page 34-21.
The Line Width set data request lets you set the width of linear and areal tactical graphics.
To set the color of a linear or areal tactical graphic:
Select a tactical graphic.
Choose Set Appearance Line Width. The Line Width dialog box opens.
Type a value, in pixels, in the Line Width box.
Click OK.
You can set the notification level for console messages without opening the Information dialog box. For details, please see “Notify Level,” on page 34-28.
Setting the State of Tactical Graphics — Pen Style
The Pen Style set data request lets you specify the type of line used to draw linear and areal tactical graphics. This includes solid lines and varies combinations of dashes and dots.
To set the pen style of a linear or areal tactical graphics:
Select a tactical graphic.
Choose Set Appearance Pen Style. The Pen Style dialog box opens.
Select an option from the Pen Style list.
Click OK.
Remote graphics are graphics that are drawn onto the scene by remote programs that use the VR-Vantage Remote Draw API. This chapter explains how to display them in VR-Forces.
Displaying Remote Graphics 41-2
Viewing a List of Remote Graphics 41-4
VR-Forces can display graphics sent from other applications using the VR-Vantage Remote Draw API (Figure 41-1).
To enable or disable the display of remote graphics:
Choose Settings Display. The Display Settings dialog box opens.
Select the Tactical Graphics Display Settings page (Figure 41-2).
Select or clear the Show Remote Graphics check box.
You can also enable and disable remote graphics by choosing Settings
Remote Graphics.
Remote graphics can be organized into sets. There is no fixed organization. Labeling of sets is entirely at the discretion of the programmer who develops the application that generates the graphics. The Remote Graphics Panel displays remote graphics in a hier- archy by set.
The VR-Vantage Remote Draw API lets developers send data about objects as attri- bute:value pairs, for example Speed:30 KM. The attributes are organized by type using attribute group templates. You can enable and disable the display of attribute informa- tion by group and by individual attribute. Figure 41-3 illustrates the attributes for the Entity and Packet attribute group templates displayed in Figure 41-4.
Figure 41-3. Remote graphics attribute group display
To view a list of remote graphics:
Choose View Remote Graphics Panel. The Remote Graphics Panel is displayed (Figure 41-4). The Remote Graphics Sets tab lists remote graphics by set.
To hide or display a remote graphic set or individual graphic, check or clear its check box in the Remote Graphics Sets list.
To view Attribute Group Templates, select the Attribute Group Templates tab. To see the attribute display, mouse over an object for which display data is available.
VR-Forces has many visual effects that add to your understanding of the interactions between simulation objects. These include fire and detonation lines, sensor contact lines, communications lines, and emitter volumes. You can test for line-of-sight with the intervisibility feature. You can also display many different lighting effects.
VR-Forces Users Guide
Section VIII - Visual and Audio Effects
VIII-1
Section VIII - Visual and Audio Effects
VIII-2 VT MAK
42. Displaying Tactical Infor- mation and Effects
This chapter describes how to manage special visual effects that can be applied to simu- lation objects.
Many of the effects described in this chapter apply to individual entities in Stealth mode. By default, simulation objects in aggregate-level scenarios do not use 3D models. Therefore, effects such as trailing effects, smoke clouds, and fire and detonation effects are not supported.
Displaying Trailing and Decal Effects (3D Only) 42-3
Specifying Models for Trailing Effects and Decal Effects 42-4
Displaying Track Histories 42-5
Configuring Track Histories 42-6
Displaying a Terrain Profile for a Track History 42-7
Viewing Fire and Detonation Effects 42-8
Viewing Fire and Detonation Lines 42-9
Viewing Unit Combat Graphics 42-10
Pinning Task Visualizations for a Simulation Object 42-13
Displaying Sensor Contact Lines 42-13
Enabling the Display of Sensor Contact Lines 42-14
Specifying which Simulation Objects Display Sensor Contact Lines... 42-14 Configuring Sensor Contact Lines 42-15
Displaying Laser Designators 42-16
Displaying Tactical Smoke 42-17
Displaying Tactical Information and Effects
Displaying Electromagnetic Emissions 42-18
Displaying Radio Communication Lines 42-20
Enabling Radio Communications Graphics 42-21
Configuring the Lifetime and Display Mode 42-22
Configuring the Color of Radio Communication Lines 42-23
Displaying Tactical Information and Effects — Displaying Trailing and Decal Effects (3D Only)
Trailing effects and decal effects are properties of an observer mode. You can enable and disable them on a per-observer basis.
Figure 42-1 illustrates some trailing effects.
Figure 42-1. Tank tracks, dust cloud
Displaying Tactical Information and Effects — Displaying Trailing and Decal Effects (3D Only)
To enable or disable trailing effects or decal effects:
Choose Settings Display. The Display Settings dialog box opens.
Select the Observer Settings page (Figure 42-2).
Figure 42-2. Display Settings dialog box, Observer Settings
Select or clear the check box for each effect that you want to change.
Trailing effects and decal effects are configured through model definitions. (For the purposes of configuration, trailing effects are categorized as decals.) Each effect must have a model definition that uses a decal schema. Then, in an entity’s entity definition, you configure a visualizer for the effect. For details about creating model definitions, please see “Creating and Editing Model Definitions,” on page 81-9.
Track histories allow you to track the paths of simulation objects during an exercise, including the path of munitions as they travel from the shooter to the target. When track histories are enabled, each simulation object leaves a track ribbon. The ribbon is colored based on the simulation object’s force. Figure 42-3 illustrates track histories.
3D 2D
Track histories are a property of an observer mode. You can enable and disable them on a per-observer basis.
Track histories have a significant performance and memory cost. For simulations with large simulation object counts, turning track histories off can improve performance and memory usage.
To enable or disable display of all track histories:
Choose Settings Display. The Display Settings dialog box opens.
Select the observer mode for which you want to change the Track Histories setting.
Select or clear the Track Histories check box.
You can also enable or disable track histories by choosing Observer Track Histories or clicking the Track Histories button ( ) on the Observer Settings Toolbar.
Displaying Tactical Information and Effects — Displaying Track Histories
You can configure how long track history ribbons are drawn. A track history is composed of a series of segments, joined together to form a line. You can configure how long each segment is and how many segments at a time can be displayed. Drawing shorter segments improves the accuracy of the track history, but can degrade perfor- mance. Increasing the maximum number of segments provides a longer history, but can clutter up the screen if there are many simulation objects and can also affect perfor- mance. Figure 42-4 illustrates the visual result of drastically changing the segment length. The left track history uses the default segment length of 0.5 meters. The right track history has a segment length of 5000 meters.
0.5 M segment length 5000 M segment length
Figure 42-4. Track history segment length
When a track history reaches the maximum number of segments configured, it starts dropping segments from the beginning of the history (the oldest segments).
You can specify that track histories have an infinite length. In this case they never drop segments.
!
!
If you specify infinite length for track histories, it is possible that you could eventually use up all the memory in your computer and the program would crash.
To configure track histories:
Choose Settings Display. The Display Settings dialog box opens.
Select the Track History Settings page (Figure 42-5).
If you want track histories to have an indefinite length, select the Infinite Track check box.
To change the number of segments that can be displayed for a track history, adjust the Track Length slider, or enter a value in the box.
To specify the length of each track history segment, enter a value in the Segment Length box.
You can display a terrain profile for a track history. (For complete information about terrain profiles, please see Chapter 54, Using Terrain Profiles.)
The track history terrain profile does not display the track history that gets drawn in the window when you enable track histories. It creates an independent track that starts when you open the terrain profile window.
To display a terrain profile for a track history:
Select the simulation object whose track history terrain profile you want to see.
Choose Objects Track History Profile. The Terrain Profile dialog box opens. It updates as the simulation object moves.
Displaying Tactical Information and Effects — Viewing Fire and Detonation Effects
VR-Forces can display the following graphic effects when munitions are fired and deto- nated:
Flaming effects.
Smoke plumes.
Detonations.
Muzzle flashes.
Tracers. Tracers are displayed if the munition in a fire interaction is a tracer muni- tion and the munition is mapped to a tracer model. Tracers are not supported in 2D observer modes. (Entities that have weapons that support tracer munitions must enable tracer use for tracers to be displayed. For details about enabling tracer use, please see “Tracer Use,” on page 34-44.)
To enable or disable display of a fire or detonation effect, choose Observer effect, where effect is Flames, Smoke Plumes, Detonations, Muzzle Flashes, or Tracers.
Displaying Tactical Information and Effects — Viewing Fire and Detonation Lines
3D 2D
Figure 42-6. Fire line and detonation
A detonation is identified by a circle with an X through it. The detonation color indi- cates the result of the detonation, as follows:
Entity impact – white.
Ground impact – gray.
Airburst – black.
Other – white.
To enable or disable display of fire and detonation lines, choose Settings Fire / Detonate Lines.
Displaying Tactical Information and Effects — Viewing Unit Combat Graphics
When simulation objects in aggregate-level scenarios engage in combat, they display two types of graphics, attack indicators, and attack animations. Attack indicators are triangular areas that show the direction a unit is attacking. They are colored with the force of the attacker. Attack animations show where a simulation object is being attacked. The footprint sector where the attack is taking place blinks from green to white.
The graphics persist until the attack is over.
Figure 42-7. Attack indicators
To enable or disable unit combat graphics:
Choose Settings Display. The Display Settings dialog box opens.
Select the Unit Display Settings page (Figure 42-8).
Displaying Tactical Information and Effects — Viewing Unit Combat Graphics
To enable or disable attack indicators, select or clear the Show Attack Indicators check box.
To enable or disable attack animations, select or clear the Show Attack Animations check box.
Displaying Tactical Information and Effects — Visualizing Tasks
VR-Forces can display graphics that help to show the task a simulation object is executing. Figure 42-9 illustrates task visualization lines in Plan View mode and Stealth mode that show an entity moving to a location.
i Task visualizations are not available for some tasks.
You can specify that task be visualized for the selected simulation object. You can also specify that tasks be visualized on a per simulation object basis. The per-simulation object setting is saved as part of the scenario.
Figure 42-9. Task visualization
To specify that the selected simulation object show task visualization lines:
Choose Settings Display. The Display Settings dialog box opens.
Select the Show Task Visualizations for Selected Entity check box.
This setting is valid only if one simulation object is selected. If multiple simulation objects are selected, they do not show visualization lines unless you have pinned them to the simulation object.
You can also enable or disable task visualization lines by choosing Observer Task Visualizations or clicking the Task Visualizations button ( ) on the Observer Settings Toolbar.
To pin task visualizations for a simulation object:
Select the simulation object for which you want to visualize tasks.
Choose Objects Pin Task Visualizations.
You can display lines between a simulation object and the objects it detects with its sensors (Figure 42-10). Display of sensor contact lines requires two levels of control. Display of sensor contact lines is an observer-specific setting. They must be enabled in the observer mode to be displayed.
You can also configure the width and color of sensor contact lines.
Figure 42-10. Sensor contact lines
Displaying Tactical Information and Effects — Displaying Sensor Contact Lines
To enable the display of sensor contact lines:
Choose Settings Display. The Display Settings dialog box opens.
In the settings list, select Sensor Contact Lines.
You can also enable or disable sensor contact lines by choosing Observer Sensor Contact Lines or clicking the Sensor Contact Lines button ( ) on the Observer Settings Toolbar.
To display sensor contact lines for a simulation object whether it is selected or not:
Select the simulation objects for which you want to enable sensor contact lines.
Choose Objects Pin Sensor Contacts.
i This setting is saved with the scenario.
To enable display of sensor contact lines by the selected simulation objects:
Choose Settings Display. The Display Settings dialog box opens.
Select the Sensor Contact Line Settings page (Figure 42-11).
Select or clear Show For Selected.
i This setting is saved with the GUI settings.
You can set the color, line width, and arrow size of sensor contact lines.
To configure sensor contact lines:
Choose Settings Display. The Display Settings dialog box opens.
Change the values as desired.
Displaying Tactical Information and Effects — Displaying Laser Designators
3D
Range
2D
Figure 42-12. Laser designators
To display laser designators, on the Display Settings Toolbar, click the Laser Desig- nator button 
).
Displaying Tactical Information and Effects — Displaying Tactical Smoke
To display supply lines:
Choose Settings Display. The Display Settings dialog box opens.
Select or clear Show Supply Lines.
VR-Forces can display tactical smoke munitions fired by VR-Forces entities. You may want to disable tactical smoke if it obscures the observer’s view. Also, if many entities are generating smoke, it could affect performance.
Do not confuse tactical smoke and smoke plumes. Smoke plumes are a visual effect displayed when an entity is on fire. Tactical smoke visualizes a smoke munition that affects line-of-sight.
If you disable display of tactical smoke, VR-Forces continues to simulate its existence in the back-end and it continues to affect line-of-sight.
To enable or disable display of tactical smoke, choose Observer Tactical Smoke.
Displaying Tactical Information and Effects — Displaying Electromagnetic Emissions
VR-Forces can display electromagnetic emissions (emitter volumes) for entities that have emitter systems (Figure 42-13). You can configure the colors used to represent emitter frequencies and you can configure the size of the emitter volumes. (For details about configuring emitter volumes, please see “Configuring Emitter Volumes,” on page 84-2.)
3D 2D
Display of emitter volumes only affects entities that have emitter systems.
Displaying Tactical Information and Effects — Displaying Electromagnetic Emissions
To enable or disable display of electromagnetic emissions:
Choose Settings Display. The Display Settings dialog box opens.
Select the Entity Display Settings page (Figure 42-14).
Select or clear the Show Emitter Volumes check box.
You can also enable or disable emitter volumes by choosing Settings Emitter Volumes, or clicking the Emitter Volumes button ( ) on the Display Settings Toolbar.
VR-Forces can display squawk indicators when a simulation object sends a signal inter- action. It can also display communication lines between simulation objects when a VR- Forces simulation object (or a simulation object in an application built with the appro- priate MAK libraries) sends a radio message to another simulation object. You can configure a communication line’s color and lifetime. Figure 42-15 displays squawk indicators and a line-of-sight communication line.
Figure 42-15. Radio communication line and squawk indicators
Figure 42-16. Curvature of the earth communication line
You can globally enable or disable the ability to display radio communication lines. When they are enabled, you can enable and disable communication lines and squawk indicators separately.
To enable or disable radio communications graphics:
Choose Settings Display. The Display Settings dialog box opens.
Select the Radio Communications Settings page (Figure 42-17).
Select or clear the Show Radio Communications check box.
You can also enable and disable communication lines by choosing Settings Radio Communication Display or by clicking the Radio Communications button 
) on the Display Settings Toolbar.
To enable or disable communication lines:
Enable radio communication lines.
Select or clear the Show Communication Lines check box.
To enable or disable squawk indicators:
Enable radio communication lines.
Select or clear the Show Squawk Indicators check box.
You can configure how long a radio communication line is displayed. You can also configure whether it is displayed using line-of-sight or curvature of the earth.
To configure the lifetime and display mode for radio communication lines:
Choose Settings Display. The Display Settings dialog box opens.
Select the Radio Communications Settings page (Figure 42-17).
To specify how long a communication line or squawk indicator should be displayed, enter a value, in seconds, in the Communication Line Lifetime and Squawk Indicator Lifetime fields.
To specify the display mode, select an option in the Communication Line Display Mode list.
If you select Curvature of the Earth, adjust the Curved Earth Exaggeration slider to change the degree to which the curvature is exaggerated.
By default, radio communication lines are green. You can configure communication lines to use force coloring or to be colored based on the frequency of the message.
When you color by frequency, you specify colors for the frequency ranges you are inter- ested in and a color to use for all messages outside the specified frequencies.
To configure the color of radio communication lines:
Choose Settings Display. The Display Settings dialog box opens.
Select the Radio Communications Settings page (Figure 42-17).
To color radio communication lines using the force color, select the Use Force Coloring option.
To color radio communication lines by frequency:
Select the Use Custom Colors option.
Click the Add button ( ). A range is added to the frequency list with a default color (Figure 42-18).
Double-click the starting value of the range to make it editable (Figure 42-19).
Type the starting frequency you want to use.
Edit the end frequency.
Double-click the color swatch and select a color for this range.
Optionally, add points for different frequency ranges.
Optionally, click the Outside Range Color color swatch and specify a color for all frequencies not specified in the frequency list.
If you configure multiple frequency ranges, you cannot add a range whose values are within those of an existing range.
This chapter describes the lighting effects supported by VR-Forces.
Displaying Lighting Effects 43-2
Enabling and Disabling Lighting 43-3
Configuring Ambient and Diffuse Lighting 43-4
Specifying the Emissive Lighting Scale 43-5
Displaying Dynamic Lighting 43-6
Daylight Control of Lights 43-7
Displaying Ocean Planar Reflections 43-8
Configuring Ocean Planar Reflections 43-10
Displaying Crepuscular (Sun) Rays 43-12
Configuring the Skybox Cube Map 43-14
Using High Dynamic Range Lighting 43-16
Disabling Lighting and Clouds 43-18
Displaying Shadows (3D Only) 43-19
Lighting Effects — Displaying Lighting Effects
VR-Forces can simulate a variety of lighting effects, including:
Dynamic lighting
Ocean planar reflection
Lens flare
Crepuscular (sun) rays.
Shadows.
Use of lighting effects affects performance. VR-Forces lets you enable and disable some effects so you can adjust the mixture of performance and effects that best meets your needs.
When lighting is enabled, VR-Forces takes into account direct and ambient lighting when it renders a scene. During the daytime, objects are brightly lit. At night, you cannot see them unless an object is casting light on them or you use a sensor mode that provides night vision.
If lighting is disabled you can see objects regardless of the time of day. Lighting may not be realistic.
To enable or disable lighting:
Choose Settings Display. The Display Settings dialog box opens.
Select the Lighting Render Settings page (Figure 43-1).
Select or clear the Enable Lighting check box.
Lighting Effects — Enabling and Disabling Lighting
Ambient lighting is the lighting available to objects that are not in a direct form of light, such as sunlight. Diffuse lighting is light that is reflected off an object. You can adjust the overall amount of ambient and diffuse lighting in the scene and you can configure whether objects use the material ambient and diffuse values specified in their models or use values provided by VR-Forces.
You can set a scale factor for ambient and diffuse light that is present in the scene. Lower values make objects darker. Higher values make them lighter. The ambient or diffuse scale factor is independent of how material ambient and diffuse values are set.
To specify the ambient and diffuse lighting scale values:
Choose Settings Display. The Display Settings dialog box opens.
Select the Lighting Render Settings page (Figure 43-1).
Adjust the Diffuse Scale slider or change the value in the box.
Adjust the Ambient Scale slider or change the value in the box.
Polygons in a 3D scene have a material and a texture. Polygon materials may specify specular, diffuse, and ambient colors that define the way they respond to incoming light.
In addition to specifying which material ambient and diffuse values to use, you can set a scale factor. Lower values make objects darker. Higher values make them lighter. The material ambient or diffuse scale factor is independent of how ambient and diffuse values are set for scene lighting.
To configure the material ambient value:
Choose Settings Display. The Display Settings dialog box opens.
Select the Lighting Render Settings page (Figure 43-1).
To use the ambient values specified by objects, clear the Use Global Ambient Value check box. To have VR-Forces use a global value, select the Use Global Ambient Value check box.
If you selected the Use Global Ambient Value check box, optionally, adjust the Global Ambient Value slider or change the value in the box.
To configure the material diffuse value:
Choose Settings Display. The Display Settings dialog box opens.
Select the Lighting Render Settings page (Figure 43-1).
To use the diffuse values specified by objects, clear the Use Global Diffuse Value check box. To have VR-Forces use a global value, select the Use Global Diffuse Value check box.
If you selected the Use Global Diffuse Value check box, optionally, adjust the Global Diffuse Value slider or change the value in the box.
You can change a scale value that controls the brightness of emissive textures. This allows you to make windows, street lights, and other emissive light sources darker or brighter. Increasing the scale value increases the brightness.
To specify the emissive lighting scale value:
Choose Settings Display. The Display Settings dialog box opens.
Select the Lighting Render Settings page (Figure 43-1).
Adjust the Emission Scale slider or change the value in the box.
Lighting Effects — Displaying Dynamic Lighting
VR-Forces can display light cast by light sources such as headlights, street lamps, and spotlights. Display of dynamic lighting is an observer-specific feature. It is disabled by default.
Figure 43-2 shows a night-time scene with dynamic lighting enabled. The HMMWV’s taillights cast light to the rear. The headlights cast light forward. Street lamps and windows are also casting light.
Figure 43-2. Dynamic Lighting enabled
Light points that are part of the terrain, such as runway lights, automati- cally turn on at dusk and turn off at dawn.
Emissive lights, such as automobile headlights, are always on. You cannot change these lighting settings.
Lighting Effects — Displaying Dynamic Lighting
To enable dynamic lighting,
Choose Settings Display. The Display Settings dialog box opens.
Select the Observer Settings page.
In the list of settings, select Dynamic Lights.
You can also enable or disable dynamic lighting by choosing Observer
Dynamic Lights.
Some types of lights turn on and off automatically based on the time of day. Light points:
Light points in an OpenFlight file that has been loaded as a terrain patch are auto- matically discovered and placed under daylight control.
Light points in an earth file that are created with model statements that have a feature name registered with the lightPointInstaller module in ../appData/import- Config/registrant_feature_list.csv (default is “lights”) are placed under daylight control. The following example shows earth file syntax:
<model name="alamoana-lights" driver="feature_geom" >
<features name="lights" driver="ogr">
<url>../../data/Terrain/Hawaii/Features/InfrastructureP.shp</url>
</features>
Light points in an OpenFlight file that has been loaded as an articulated model use the daylightControlledLights model definition parameter.
S57 navigation lights use the EXCLIT attribute found in the S57 data for each light.
Lights placed when creating procedural airports use standard model definitions. For example, the PAPI lights use the LightPAPILeft and LightPAPIRight model definitions. The daylightControlledLights parameter determines whether these lights are under daylight control.
Light sources (lights that cast light onto other objects) are discovered on the cull pass of the scene graph. Sources found under the terrain root or props root of the scene graph are automatically put under daylight control.
Lighting Effects — Displaying Ocean Planar Reflections
VR-Forces can show the reflection of terrain and objects on water (Figure 43-3). To see planar reflections, dynamic ocean must be enabled. (For details about enabling dynamic ocean, please see “Enabling Marine Effects,” on page 11-17.)
Displaying ocean planar reflections degrades performance.
Figure 43-3. Ocean planar reflection
Lighting Effects — Displaying Ocean Planar Reflections
To enable or disable planar reflections:
Choose Settings Display. The Display Settings dialog box opens.
Select the Ocean Settings page (Figure 43-4).
Select or clear the Enable Ocean Planar Reflections check box.
Lighting Effects — Lens Flare
To reduce the performance impact of ocean planar reflections, you can configure the LOD scale. The LOD scale affects the distance from the observer at which VR-Forces switches LODs. The higher the value, the more quickly LODs are switched.
The Texture Height and Texture Width parameters affect the resolution of the ocean planar reflection texture, in pixels. Higher resolution decreases performance.
To configure ocean planar reflections:
Choose Settings Display. The Display Settings dialog box opens.
To change the ocean planar reflection LOD scale, adjust the LOD Scale slider under Enable Ocean Planar Reflections, or change the value in the box.
To change the width or height of the ocean planar reflection texture, adjust the Texture Width or Texture Height slider under Enable Ocean Planar Reflections, or change the values in the boxes.
Lens flare is a visual artifact often seen when looking at light sources such as the sun through a camera lens (Figure 43-5). VR-Forces can simulate lens flare when the observer looks towards the sun.
Lighting Effects — Lens Flare
i Lens flare is supported only when high dynamic range lighting is enabled.
To enable or disable lens flare:
Choose Settings Display. The Display Settings dialog box opens.
Select the High Dynamic Range Settings page (Figure 43-6).
Select or clear the Enable Lens Flare check box.
Lighting Effects — Displaying Crepuscular (Sun) Rays
VR-Forces can simulate the effect of crepuscular rays (sunbeams) beaming through clouds (Figure 43-7).
Lighting Effects — Displaying Crepuscular (Sun) Rays
To enable or disable crepuscular (sun) rays:
Choose Settings Display. The Display Settings dialog box opens.
Select the Render Settings page (Figure 43-8).
Select or clear the Enable Crepuscular Rays (Sun Rays) check box.
Lighting Effects — Configuring the Skybox Cube Map
A skybox cube map is a graphics technique used to render reflections and sky effects. The skybox cube map is rendered from the location of the observer. As the observer moves, the cube map needs to be recalculated, which is computationally expensive.
VR-Forces lets you configure the distance that the observer has to move (the skybox cube map regeneration threshold) before it recalculates the cube map. Increasing the threshold can improve performance, at the cost of visual quality.
You can also choose to omit clouds in the skybox cube map. Omitting clouds can increase performance.
To configure the skybox cube map:
Choose Settings Display. The Display Settings dialog box opens.
Adjust the Skybox Cube Map Regeneration Threshold slider or enter a value in the box.
Optionally, select the Omit Clouds in Cube Map check box.
Lighting Effects — Flashlight Mode
VR-Forces can light a circular area as if the observer is using a flashlight. You can move the flashlight beam and increase or decrease the diameter of the flashlight beam.
Figure 43-9. Flashlight mode
To turn flashlight mode on or off, press f.
To move the flashlight beam, hold down Alt and the right mouse button and move the mouse.
To change the size of the flashlight beam, hold down Alt and move the mouse scroll wheel forward or back.
Lighting Effects — Using High Dynamic Range Lighting
High dynamic range (HDR) lighting makes scenes look more realistic. They look particularly good on HDR monitors. HDR is enabled by default.
To configure HDR lighting:
Choose Settings Display. The Display Settings dialog box opens.
To enable or disable HDR lighting, select or clear the Enable HDR check box.
Enable other settings as desired.
For those settings that are enabled, adjust their parameters. Table 43-1 describes the HDR settings.
Setting Description
Setting Description
Enable HDR Turn High Dynamic Range (HDR) on/off. When HDR is turned on the scene is rendered in full 16-bits per color floating point and then tone mapped to 8-bits per color before being sent to the display. Additionally, there are post process effects applied to objects that are greater than the display range.
Enable Auto Exposure
Turn on/off auto exposure, which is a post process that scales the intensity of the rendered image based on the intensity of the screen. When auto exposure is turned off the global lighting values are used to scale the intensity to a reasonable value.
Enable Bloom Turn on/off the bloom post process effect. This effect is a blur- ring of high intensity objects in the scene which gives a glow around bright objects like light points.
Enable Streaks Turn on/off the streak post process effect. This effect creates a star effect by streaking the high intensity objects in all direc- tions.
Enable Lens Flare Turn on/off the lens flare post process effect. This effect creates a lens flare effect for high intensity objects.
Light Point Scale When HDR is turned on, light point intensity is scaled by this setting.
Dynamic Light Scale
Emissive Texture Scale
When HDR is turned on, the intensity of dynamic lights are scaled by this setting.
When HDR is turned on, the intensity of the emissive textures are scaled by this setting.
Specular Scale When HDR is turned on the lighting specular component is scaled by this setting.
Lighting Effects — Using High Dynamic Range Lighting
Table 43-1: HDR settings
Setting Description
Setting Description
Shininess Scale When HDR is turned on the lighting shininess component is scaled by this setting. Exposure adjustments are all related to how the intensity of the scene is scaled before being tone mapped. These values are in order based on when they are applied to the scalar.
Rate Scale When Auto Exposure is enabled, this scales the time it takes for the auto exposure to adjust to changes in the scene. Increase this value to reduce the time it takes for the auto exposure to adjust.
Pre Scale When Auto Exposure is enabled, this scales the calculated inten- sity for the scene. Increase this value to reduce the overall inten- sity of the final image.
Min Difference When Auto Exposure is enabled, this clamps the minimum value of the calculated intensity to a portion of the global lighting value. This is used to prevent the auto exposure from going too low compared to the global lighting value.
Max Difference When Auto Exposure is enabled, this clamps the maximum value of the calculated intensity to a portion of the global lighting value. This is used to prevent the auto exposure from going too high compared to the global lighting value.
Post Scale Scales the scalar after all Auto Exposure calculations have been done. This also affects the global lighting value when Auto Exposure is turned off. Increase this value to reduce the overall intensity of the final image.
Final Clamp Min Minimum value for the final value that will be used to scale the intensity prior to tone mapping.
Final Clamp Min Maximum value the final value that will be used to scale the intensity prior to tone mapping.
Bloom Scale Scales the bloom before it is applied to the scene. Increase this value to increase the intensity of the bloom effect on high inten- sity objects.
Streak Intensity Scale
Number of Streaks
Streak Length Scale
Streak Rotation Offset
Scales the streaks before they are applied to the scene. Increase this value to increase the intensity of the streak effect on high intensity objects.
Number of streaks that the streak effect will create for each high intensity object. Maximum of 8 streaks.
Scales the length of the streak effect. Increase this value to increase the length of the streak effect.
Rotates the streak effect so that it changes the direction that the streaks point.
Lighting Effects — Disabling Lighting and Clouds
Table 43-1: HDR settings
Setting Description
Setting Description
Lens Flare Scale Scales the lens flare effect before it is applied to the scene. Increase this value to increase the intensity of the lens flare effect.
Gamma Final color correction used to adjust the image based on the display. Change this value based on the characteristics of the display being used.
When you are using XR observer mode and you move the observer out from the terrain, the lighting and cloud effects can interfere with your ability to view simulation objects. Therefore, VR-Forces lets you quickly disable lighting effects and clouds. By default, they are enabled in Stealth observer mode and disabled in XR observer mode.
To enable or disable lighting and clouds, choose Observer Sky.
VR-Forces can display shadows for entities, props, and terrain features.
Figure 43-10. Shadows
You can enable and disable shadows and you can configure shadow quality.
i Enabling shadows can affect performance.
To enable and disable shadows globally:
Choose Settings Display. The Display Settings dialog box opens.
Select the Shadow Settings page (Figure 43-11).
Select or clear the Enable Shadows check box.
i You can also enable and disable shadows by choosing Settings Shadows.
You can configure which objects cast shadows and parameters that affect performance and the quality of shadows. Shadow parameters include the following:
Cascades. A scene is split into sections, with those closest to the camera showing the highest resolution shadows. You can configure the number of splits and how the quality of resolution changes as you move away from the camera.
Polygon offset. These settings shift shadows to minimize Z-fighting.
Shadow ambient factor. Hides Z-fighting and other visual artifacts.
Shadow stability. Affects resolution when the camera moves.
Filtering. These options affect visual quality.
Sample Distribution Shadow Maps (SDSM). SDSM increases rendering quality at the expense of performance.
To configure how shadows are rendered:
Choose Settings Display. The Display Settings dialog box opens.
To enable or disable shadows for object types, select or clear the Entities Cast Shadows, Props Cast Shadows, or Terrain Casts Shadows check boxes.
Change other parameters as desired.
This chapter describes different marine effects and water droplets.
Displaying Water Droplets and Splash Effects 44-2
Setting the Size of Water Droplets 44-5
Enabling High Quality Rotor Wash 44-5
Displaying Wakes and Spray Effects 44-6
Enabling Buoyancy for Surface Entities 44-7
When it is raining, VR-Forces can simulate raindrops hitting the observer’s camera lens (Figure 44-1). If the observer is close to the surface of the ocean (as if a periscope were being raised or lowered), VR-Forces can simulate the effect of waves and water droplets splashing on the observer’s camera.
When dynamic ocean is enabled, VR-Forces can simulate sea spray (most visible in high seas) (Figure 44-2). It can also display rotor wash for hovering helicopters. You can display rotor wash at two levels of quality.
Figure 44-2. Sea spray effects
You can change the size of the water droplets for splash effects and sea spray. For details, please see “Setting the Size of Water Droplets,” on page 44-5.
To enable or disable splash effects:
Choose Settings Display. The Display Settings dialog box opens.
Select the Observer Settings page (Figure 44-3).
Select or clear the Rain Splash, Wave Splash, or Ocean Spray effect check boxes.
To enable sea spray effects:
Choose Settings Display. The Display Settings dialog box opens.
Select the Ocean Settings page (Figure 44-4).
Select Enable Sea Spray Particle Effects.
You can change the size of water droplets for splash effects and sea spray.
To change the size of water droplets:
Choose Settings Display. The Display Settings dialog box opens.
Select the Render Settings page (Figure 44-5).
Adjust the Water Droplets Size slider or enter a value in the box.
To enable high quality rotor wash:
Choose Settings Display. The Display Settings dialog box opens.
Select Enable High Quality Rotor Wash.
Marine Effects — Displaying Wakes and Spray Effects
When dynamic ocean is enabled, surface entities display wakes and spray effects. However, these effects affect performance. You can disable them if you need to empha- size performance over visual effects.
Wakes have their own schema, with many attributes, including length, offset, the amount of time over which they fade out, and LOD distance. You can edit these attri- butes for individual entities in the Visual Model Editors dialog box.
To enable or disable wakes and spray effects:
Choose Settings Display. The Display Settings dialog box opens.
Select the Entity Display Settings page (Figure 44-6).
To enable or disable wakes, select or clear the Enable Wakes on Dynamic Oceans check box.
If wakes are enabled, select Enable Spray Effects on Surface Vehicles to enable spray effects. Clear the check box to disable them. Disabling wakes also disables spray effects.
Marine Effects — Enabling Buoyancy for Surface Entities
When dynamic ocean is enabled, surface entities can bob up and down with
wave action. However, the buoyancy models affect performance. You can disable buoy- ancy if you need to emphasize performance over visual effects. You can also control the area in which buoyancy models are calculated.
If buoyancy is enabled, VR-Forces calculates buoyancy only for models within certain distances of the observer, as follows:
Buoyancy models are always calculated for entities within the minimum cull distance. This ensures that if the observer turns, entities that are relatively near will show buoyancy immediately.
Buoyancy models are not calculated for entities beyond the far clipping plane or nearer than the near clipping plane.
VR-Forces uses the nearer of the far clipping plane or the maximum buoyancy LOD range to determine the distance at which it stops calculating buoyancy models.
Marine Effects — Enabling Buoyancy for Surface Entities
When buoyancy is enabled, you can specify that VR-Forces use face front culling. VR- Forces calculates buoyancy models for all entities within the minimum range and all entities between the near clipping plane and the far clipping plane or maximum buoy- ancy LOD range, whichever is closest. In Figure 44-7, the shaded area is the area in which buoyancy models are calculated.
far clipping plane or maximum LOD distance
near clipping plane
near clipping plane
minimum range
Observer
Figure 44-7. Face front culling
By default, face front culling is disabled and only distance culling is used.
To enable or disable the buoyancy models:
Choose Settings Display. The Display Settings dialog box opens.
Select or clear the Enable Buoyancy Models for Surface Vehicles check box.
To specify the distance beyond which buoyancy models are not calculated, adjust the Default LOD Distance slider or change the value in the box. (If the default distance is set to 0, then entities that do not have an LOD range set in their model definitions will have an infinite buoyancy range. However, buoyancy will not be calculated past the far clipping plane.)
To specify the radius within which all entities have their buoyancy models calcu- lated, adjust the Minimum Cull Distance slider or change the value in the box.
Optionally, specify use of face front culling.
This chapter explains how to enable and configure simulated night-vision goggle (NVG) and infrared views of the scene.
Using Sensors — Using Sensors
VR-Forces can simulate the way that the 3D scene would look if an observer were using visual sensor devices such as night vision goggles or viewing the infrared spectrum. This is an observer-specific setting. You can adjust the contrast, blur, and noise of the view.
VR-Forces includes one sensor module – CameraFX, which uses the SenSim libraries from JRM Technologies. The sensors do not take into account the materials of the objects that you are viewing. They simply filter the view to produce the desired effect.
No sensor (daylight) IR sensor
Figure 45-1. CameraFX
The sensors described in this chapter are strictly visual effects. They have no relationship to the sensor systems used by simulation objects.
Using Sensors — Enabling Sensors
Sensors are observer-specific (Figure 45-2). VR-Forces includes observer modes that have sensors enabled. The names of the observer modes match the sensor modes that they enable.
NVG (CameraFX).
IR (CameraFX).
IR BlackHot (CameraFX)
Camera (CameraFX). This mode uses the Visual Camera sensor mode.
Figure 45-2. Sensor setting for observer mode
The default settings for the Camera observer mode make it look very similar to Stealth observer mode. The difference is that when you use the Camera observer mode, you can change the view by changing the sensor settings, such as blur, noise, and gain.
You can also specify use of a sensor configuration as a channel attribute.
To enable sensors, do one of the following:
Select an observer mode that has a sensor configured.
Edit an observer mode to use a sensor.
Create a new observer mode and configure it with a sensor.
Change the Sensor attribute for a channel.
For details about creating and editing observer modes, please see “Creating and Editing Observer Modes,” on page 48-3. For details about editing channel attributes, please see “Changing a Channel’s Attributes,” on page 77-7.
Using Sensors — Configuring Sensors
You can configure the following aspects of sensors:
Blur. The sharpness of the image.
Noise. The graininess of the image.
Gain. The contrast and brightness of the image. (IR only)
You can configure a separate set of settings for each sensor type. VR-Forces remembers the settings. When you change the settings for a sensor type, they affect the display only if that sensor type is in use. For example, if you select NVG in the sensor list on the Observer Settings page, and select IR in the Sensors list on the Sensor Settings page, the changes you make to the IR configuration do not affect the NVG display you are looking at. If you then switch to IR in the VR-Forces window, the new IR settings take effect. (This probably sounds obvious, but the Sensor Settings page does not automati- cally display the configuration for the sensor that is being used. If you want to edit the sensor that you are currently using, you have to be sure that you have selected it to edit.)
To configure sensors:
Choose Settings Display. The Display Settings dialog box opens.
Select the Sensor Settings page (Figure 45-3).
In the Sensor Mode list, select the sensor that you want to configure.
Select the Sensor module from the list.
Select the sensor mode (Monochrome, NVG, and so on). If you select Infrared Mode, select or clear the Black Hot Mode check box.
Using Sensors — Adding New Sensors
It may seem obvious that if, for example, you select NVG from the Sensor Mode list, you would select it for the sensor type. However, VR- Forces lets you add additional sensor configurations to the list and in that case, you would need to specify the correct sensor type for the new sensor. For example, you might create a sensor called NVG-High Contrast. Then you would select NVG as the sensor type and adjust the contrast accordingly.
Select the check boxes for the effects that you want to be enabled for this sensor configuration.
Adjust the values for the enabled effects.
You can add, rename, and delete sensors.
To add a sensor:
Choose Settings Display. The Display Settings dialog box opens.
Select the Sensor Settings page (Figure 45-3).
On the Sensor Mode line, click the Add button ( ). A new sensor called sensor_number is added. There are no configuration options on the page. (To rename the sensor, click the Rename button ( ) and enter a new name.)
In the Sensor Module list, select CameraFX. The available configuration options are added to the page.
Select the type of sensor that you want this to be (Full Color, Monochrome, Infrared, or NVG).
Set the Blur, Noise, and Gain levels.
Using Sensors — Adding New Sensors
This chapter explains how to use the intervisibility feature.
Intervisibility (Line-of-Sight) 46-2
Point-to-Point Intervisibility 46-3
Intervisibility Objects can be Transient or Permanent 46-5
Creating a Transient Intervisibility Object 46-6
Creating a Permanent Intervisibility Object 46-7
Editing an Intervisibility Object 46-8
Configuring Intervisibility Lines and Fans 46-9
Pinning an Intervisibility Object to a Simulation Object 46-10
Showing and Hiding Intervisibility Lines 46-10
Displaying Intervisibility Line Information 46-11
Displaying an Intervisibility Line’s Terrain Profile 46-12
Deleting Intervisibility Objects 46-12
Intervisibility — Intervisibility (Line-of-Sight)
You can display a terrain profile for point-to-point intervisibility lines.
Tanks can see each other
Tanks cannot see each other
Figure 46-1. Intervisibility
You can configure parameters for intervisibility objects, such as the height above the terrain from which intervisibility is calculated. You can also change the colors used to display intervisibility.
By default, intervisibility between simulation objects is calculated from the center of their bounding volumes. The VR-Forces target detection sensor uses an offset, which is often above the center of the entity. Unless you change the Origin LOS Elevation value in the Intervisibility Options dialog box to use the same offset as the target detection sensor, simula- tion objects may shoot at targets for which they do not appear to have line-of-sight.
Linear and areal features do not block line-of-sight. Only point features block LOS.
Intervisibility — Types of Intervisibility
VR-Forces supports the following types of intervisibility:
Point-to-point (intervisibility line).
Intervisibility fan.
Entity intervisibility.
The intervisibility fan and entity intervisibility are displayed as a circular area. However, intervisibility calculations are made within a cylindrical area extending above and below the terrain, so that intervisibility calculations can be made for air platform entities and subsurface entities.
In the 2D view, intervisibility lines are fully visible on the terrain. In the 3D view, they may pass through the terrain.
Point-to-point intervisibility (Figure 46-2) shows the line-of-sight between any two points. The portion of the line that is visible from the starting point is green. The portion that is not visible is red. You can change the colors used.
2D 3D
Figure 46-2. Point-to-point intervisibility
Intervisibility — Types of Intervisibility
An intervisibility fan (Figure 46-3) shows a series of lines radiating from the center of a circle to its outer edge. Each ray shows intervisibility along its path from the origin to the border. You can configure the distance between rays. (For details, please see “Configuring Intervisibility Lines and Fans,” on page 46-9.)
2D 3D
Figure 46-3. Intervisibility fan
Entity intervisibility (Figure 46-4) shows which simulation objects are visible from the center of a defined area and whether or not the simulation objects can see the center point. If you center the intervisibility circle on a point on the terrain, you can see which simulation objects can see that point. If you lock the circle to a simulation object, you can see which simulation objects can see that object and which it can see. (For details, please see “Configuring Intervisibility Lines and Fans,” on page 46-9.)
2D 3D
Figure 46-4. Entity intervisibility
You can configure intervisibility objects to be transient or permanent. (For details, please see “Configuring Intervisibility Lines and Fans,” on page 46-9.) A transient intervisibility object displays intervisibility from the origin point (defined by a mouse click) to wherever you move the cursor. If you click the mouse again, you reset the origin. You cannot use the mouse for other actions until you exit intervisibility mode (by right-clicking). This mode is convenient when you want to quickly check intervisi- bility, but do not want to keep intervisibility objects in the display.
A permanent intervisibility object stays in the display after you create it. You can resize the object, edit drawing options, and move it around the display. Intervisibility objects are not saved as part of the scenario.
Intervisibility — Intervisibility Objects can be Transient or Permanent
Transient intervisibility objects do not stay in the display after you quit intervisibility mode.
To display transient intervisibility:
Choose Settings Display. The Display Settings dialog box opens.
Select the Intervisibility Settings page (Figure 46-5).
Clear the Left Click Makes Objects Permanent check box.
Choose Intervisibility Create intervisibility_type, where intervisibility_type is a type of intervisibility object, or click one of the buttons on the Intervisibility Toolbar.
Click on the terrain to place the origin of the intervisibility object.
Move the cursor around the terrain to expand and contract the object. For point- to-point intervisibility, moving the cursor also changes the direction of the line.
To change the origin of the intervisibility display, click another location on the terrain.
Right-click to cancel intervisibility mode.
To create a permanent intervisibility object:
Choose Settings Display. The Display Settings dialog box opens.
Select Enable Intervisibility Objects.
Select Left Click Makes Objects Permanent.
Choose Intervisibility Create intervisibility_type, where intervisibility_type is a type of intervisibility object, or click one of the buttons on the Intervisibility Toolbar.
Click on a simulation object or on a location on the terrain where you want the origin of the intervisibility object to be located. An intervisibility object is displayed. As you move the cursor closer to the origin, or farther away from it, the circle or line contracts and expands. If you are displaying point-to-point, you can rotate the line around the origin before you specify the end point.
Click on the terrain where you want to fix the end point of a line or border of a circle.
Intervisibility — Editing an Intervisibility Object
You can change the following aspects of an intervisibility object:
The location of either end point of an intervisibility line, to change its length and direction.
The origin of an intervisibility fan, thereby moving the entire fan.
The diameter of an intervisibility fan.
If an intervisibility object is anchored to a simulation object, you cannot change the origin.
To change the length or diameter of an intervisibility object:
To edit a line, double-click its end point.
To edit a fan, select the object, then double-click the outer ring of the fan. The cursor changes 
).
Drag the end point or circle towards or away from the origin. If you are editing an intervisibility line, you can move the end point to any location.
Click to exit edit mode.
To revert to the original size of the intervisibility object, right-click while you are still in edit mode.
To move an intervisibility fan or line:
Double-click a fan’s center point or any place on a line. The cursor changes.
Drag the object to a new location.
Click to set the location.
To revert to the original location of the intervisibility object, right-click while you are still in edit mode.
Intervisibility — Configuring Intervisibility Lines and Fans
You can configure the following attributes of intervisibility objects:
The elevation of the origin and end point.
The update rate for entity intervisibility fans.
Display of height above terrain lines (3D) and height labels (3D and 2D).
The colors used to display intervisibility objects.
Display of range and bearing labels. For more information about range and bearing labels, please see “Displaying Intervisibility Line Information,” on page 46-11.
When you change colors or the sampling rate, changes affect all existing intervisibility objects. Changes to the origin and end point elevation only affect newly created objects.
To configure intervisibility objects:
Choose Settings Display. The Display Settings dialog box opens.
Change the settings as desired. Table 46-1 describes the settings.
Table 46-1: Intervisibility settings
Option Description
Option Description
Enable Height Above Terrain Lines
Show Height Above Terrain Lines Only for Selected
Enables or disables display of height above terrain lines (3D) and height labels (3D and 2D).
If selected, HAT lines are displayed only for the selected intervisibility objects.
Object Origin Elevation The height, in meters, above the terrain at the origin
point from which to calculate intervisibility.
Object End Point Eleva- tion
The height, in meters, above the terrain at the end point to use to calculate intervisibility.
Fan Line Sample Interval The distance, in degrees, between each ray in a intervisi-
bility fan. After changing this value, press Enter or click away from the field.
Entity Fan Update Interval How frequently, in seconds, to update the entity intervis-
ibility fan.
Visible Color Blocked Color
The colors to use for the portion of an intervisibility line that a simulation object can see and the portion where visibility is blocked.
Circle Color The color to use for the outer circle of an intervisibility fan.
Show Range and Bearing Labels
Enable or disable display of range and bearing labels.
Intervisibility — Pinning an Intervisibility Object to a Simulation Object
Table 46-1: Intervisibility settings
Option Description
Option Description
Background Color Specify the background color for range and bearing
labels.
Background Opacity Specify the opacity of the background for range and
bearing labels.
Show Location Field If range and bearing labels are displayed, show the loca-
tion of the endpoints.
Show Change in Altitude Field
If range and bearing labels are displayed, show the differ- ence in altitude between the endpoints.
Show Heading Field If range and bearing labels are displayed, show the
heading of each endpoint relative to the other point.
Show Range Field If range and bearing labels are displayed, show the length
of the intervisibility line.
When you pin an intervisibility object to a simulation object, the intervisibility object moves with the simulation object and you know that its origin is centered on the simu- lation object.
To pin an intervisibility object to a simulation object:
Select the simulation object to which you want to pin the intervisibility object.
Choose Intervisibility Create intervisibility_type, where intervisibility_type is a type of intervisibility object, or click one of the buttons on the Intervisibility Toolbar. The origin is placed on the simulation object icon or model.
Specify the end point for the intervisibility object.
You can toggle the display of intervisibility lines on and off.
To enable or disable the display of intervisibility lines:
Choose Settings Display. The Display Settings dialog box opens.
Select or clear the Enable Intervisibility Objects check box.
You can also enable and disable display of intervisibility objects by choosing Intervisibility Enable/Disable Intervisibility, or by clicking the Enable/Disable Intervisibility button ( ) on the Intervisibility Toolbar.
Intervisibility — Displaying Intervisibility Line Information
You can display the following information about an intervisibility line:
Location of each endpoint.
Heading of the line from each endpoint.
Altitude of each endpoint.
Length of the line (range).
Figure 46-6. Intervisibility line information (2D)
The information label has a background. You can adjust the color and opacity of the background.
To display information about an intervisibility line:
Choose Settings Display. The Display Settings dialog box opens.
Select or clear the Show Range and Bearing Labels check box.
Select the check boxes for the type of information you want to display. For descrip- tions of the check box options, please see Table 46-1.
To change the background color for the label:
Click the Background Color button. A color picker opens.
Select the color you want to use for the background.
Click OK.
To change the opacity of the background, adjust the Background Opacity slider.
Intervisibility — Displaying an Intervisibility Line’s Terrain Profile
By default, a terrain profile window is displayed automatically when you create an intervisibility line. The terrain profile can be very helpful when you try to understand how terrain changes are affecting intervisibility. Figure 46-7 shows an obstructed inter- visibility line and its terrain profile, whose graph illustrates the line intersecting the terrain.
Figure 46-7. Terrain profile for an intervisibility line
You can disable this setting on the Display Settings dialog box, Terrain Profile Settings page. For details, please see “Configuring Terrain Profiles,” on page 54-3.
Before you delete an intervisibility object, note the following:
If you delete a simulation object that has an intervisibility object pinned to it, the intervisibility object also gets deleted.
To delete an intervisibility object, select the object and choose Intervisibility
Delete.
VR-Forces can play sound effects for entities, fire events, and detonation events.
Introduction to Sound Effects 47-2
Specifying the Range in which Sounds are Heard 47-3
Associating Sound Files with Entities and Events 47-4
Mapping a Sound File to an Entity 47-5
Mapping Sound Files to Fire and Detonation Events 47-8
Sound Effects — Introduction to Sound Effects
VR-Forces can associate sound effects with entities, fire events, and detonation events. You can enable and disable use of sound effects and you can specify that sounds will be heard only when the observer is within a certain distance of the entity or event that generates them.
i Sound effects are not supported on Linux.
To enable sound effects:
Choose Settings Audio Settings. The Audio Settings dialog box opens.
Select the Audio Settings page (Figure 47-1).
Select the Enable Sound check box.
You can also enable and disable sound effects by clicking the Audio button 
) on the Display Settings toolbar.
Sound Effects — Enabling Sound Effects
You can adjust the volume of sound effects.
To set the sound volume:
You can specify that sound effects be played only if the observer is within a certain distance of the entities that can emit sounds. If sound range is enabled, as soon as the observer moves beyond the range from an entity, sound effects are shut off. If this option is disabled, sound effects are played for all entities in the scenario regardless of their distance from the observer. However, even if sound range is not enabled, as the distance between the observer and entities increases, sound levels drop off.
To specify the range in which sounds can be heard:
Choose Settings Audio Settings. The Audio Settings dialog box opens.
Select the Enable Sound Range check box.
Specify a value in the Sound Range text box.
VR-Forces includes a set of sound files (WAV format) for generic entity platforms and for fire and detonation events. The files are in ./data/Audio/Sounds. Sound files are asso- ciated with entity type enumerations. You can change the mappings and add new mappings.
You add and edit mappings between entity types, fire events, or detonation events and sound files on pages in the Audio Settings dialog box. You can add or edit mappings using mapping dialog boxes or directly in the mappings windows. The mapping dialog boxes behave differently depending on the state of the mapping window when you open the dialog box, as follows:
If you click the Add Mapping button and have not selected a mapping in the Entity Mapping Settings window, you are presented with a default entity type (all wildcards).
If you click the Add Mapping button and have selected an existing mapping, the dialog box displays the mapping you selected. From here, you can edit the existing mapping or create a new one.
When you edit a mapping, the result depends on whether you edit the entity or event enumeration or the sound file. The differences are based on the requirements for uniqueness in a mapping. The uniqueness of an entity type or fire event mapping is based on the entity type enumeration. The uniqueness of a detonation event mapping is based on the entity type enumeration and the detonation result value. Table 47-1 lists the results of different editing actions.
Table 47-1: Editing sound mapping files
Action Result
Action Result
Edit enumeration in dialog box. New mapping is added. The
previous mapping is not changed.
Edit enumeration in place. New mapping replaces previous
mapping.
Edit sound file in dialog box or in window.
Edit channel in dialog box or in window.
Mapping to current entity or event is updated.
Mapping to current entity or event is updated.
Edit detonation result in dialog box. New mapping is added. The
previous mapping is not changed.
Edit detonation result in window. New mapping replaces previous
mapping.
An entity type enumeration can only have one sound file mapped to it. A sound file can be mapped to as many entity types as you want.
To add a new entity sound mapping:
Choose Settings Audio Settings. The Audio Settings dialog box opens.
Select the Entity Sound Editor page (Figure 47-2).
Figure 47-2. Entity Sound Editor page
Click the Add button ( ). The Create New Entity Type Sound Mapping dialog box opens (Figure 47-3).
Figure 47-3. Create New Entity Type Sound Mapping dialog box
You cannot open the Create New Entity Type Sound Mapping dialog box with default options if one of the existing mappings is selected. If you have selected a mapping and want to return to the unselected state, click on white space in the mappings window or select one of the other tabs and then select the Entity Sound Editor tab again.
In the Entity Type box, type the enumeration for this mapping.
In the Sound File text box, type the pathname of a sound file or click Browse and select a file in the file chooser dialog box.
Click OK.
The OK button does not become enabled until you specify a valid entity type and sound file name.
When you edit a mapping, you can either change the sound file associated with the current entity type or create a new mapping with a different entity type.
To create a sound mapping from an existing mapping:
Choose Settings Audio Settings. The Audio Settings dialog box opens.
Select the mapping that you want to use as the starting point.
Click the Add button ( ). The Create Entity Type Sound Mapping from Existing Mapping dialog box opens (Figure 47-4).
Figure 47-4. Create Entity Type Sound Mapping from Existing Mapping dialog box
To change the sound file associated with the entity type, type a new pathname or click Browse and select a sound file.
To create a new mapping, change the Entity Type enumeration.
Click OK. If you just changed the sound file, the mapping is updated. If you changed the entity type, a new mapping is added to the list.
If you edit the entity type in the mappings window (that is, without using a dialog box), it replaces the previous mapping.
To edit the entity type in the window:
Choose Settings Audio Settings. The Audio Settings dialog box opens.
Double-click the entity type you want to edit. It becomes editable (Figure 47-5).
Change the entity type enumeration.
Press Enter.
When you edit the sound mapping in the mappings window, the change does not affect any other mapping.
To edit the sound mapping in the window:
Choose Settings Audio Settings. The Audio Settings dialog box opens.
Double-click the sound mapping that you want to change. The Sound File dialog box opens.
Select the new sound file.
Click Open.
The SISO Enumerations document specifies a list of detonation results, such as Entity Impact, Ground Impact, and Air Hit. The detonation result is part of the detonation message sent over the network. You can specify that a detonation sound be played only for a certain type of detonation result. If you set the result to “any” it plays for any type of detonation. If, for a particular detonation type, you map one sound to “any” and another sound to a specific detonation result, the specific detonation result takes prece- dence.
You can change fire and detonation mapping settings directly, rather than using the sound mapping dialog box, just like you can change entity type sound mappings. For details, see the sub-procedures under “Mapping a Sound File to an Entity,” on page 47-5.
To map a sound file to a weapon fire or detonation:
Choose Settings Audio Settings. The Audio Settings dialog box opens.
Select the Fire Sound Editor page or Detonation Sound Editor page (Figure 47-6), as appropriate.
Figure 47-6. Detonation Sound Editor page
Click the Add button ( ). The Create New Detonation (or Weapon Fire) Sound Mapping dialog box opens (Figure 47-7).
Figure 47-7. Create New Detonation Sound Mapping dialog box
When you click the Add button, if you have selected a mapping in the list, the Create New Sound Mapping from Existing dialog box displays the values for the selected mapping. If you change the entity type or detonation result, a new mapping is added with the new values.
In the Entity Type box, type the enumeration for this mapping.
Optionally, for detonation sounds, select an option on the Detonation list.
In the Sound File text box, type a pathname for the sound file you want to use or click Browse and select a file in the file choose dialog box.
Optionally, specify a channel in the Channel box.
Click OK.
The Observer and Viewing Scenarios
The observer, or eyepoint, is the location in the 3D or 2D environment from which you observe the scene. You can move the observer (navigate) through the scene. You can attach the observer to a simulation object or prop. When the observer is attached to a simulation object, it moves automatically with that object. You can also control the observer from a remote application using view control messages.
You can have multiple observers in a VR-Forces session. They might be associated with different windows. For example you could have an observer for the main window and one for an inset window.
The observer is such a pervasive component of the VR-Forces front-end that it is not covered in just one chapter of this manual. For more information, please see:
Chapter 49, Moving the Observer.
Chapter 50, Attaching the Observer to Objects.
VR-Forces Users Guide
Section IX - The Observer and Viewing Scenarios
IX-1
The Observer and Viewing Scenarios
Section IX - The Observer and Viewing Scenarios
IX-2 VT MAK
48. The Observer and Observer Modes
This chapter explains how to create, edit, and change observers and observer modes. For details about moving the observer, please see Chapter 49, Moving the Observer. For details about attaching the observer to simulation objects and props, please see Chapter 50, Attaching the Observer to Objects.
Switching Between the 2D and 3D Projections 48-2
Changing the Observer Mode 48-3
Creating and Editing Observer Modes 48-3
Creating an Observer Mode 48-4
Deleting an Observer Mode 48-5
Renaming an Observer Mode 48-5
Adding an Observer on the Observer Settings Page 48-6
Adding an Observer in the Display Engine Configuration Editor 48-7
Communicating Information About the Observer 48-11
Making the Observer Visible to Other Applications 48-11
Viewing and Attaching to Other Observers 48-12
Displaying Models for Remote Observers 48-12
The Observer and Observer Modes — Switching Between the 2D and 3D Projections
VR-Forces supports both 2D and 3D projections. You can switch between them simply by changing the observer mode from Stealth or Out-the-Window, to Plan View. (Changing observer modes is described in “Changing the Observer Mode,” on
page 48-3.) When you go from a 3D observer mode to 2D, VR-Forces calculates a zoom level so that the observer should appear as if it is roughly the same height above the terrain. When you go from a 2D observer mode to 3D, VR-Forces calculates an altitude to do the same thing, and keeps the 3D view pointing down (so the change in overall view stays fairly small).
A model set. A collection of models of a particular type, such as 3D models.
A key map. A coordinated set of key mappings to movement functions.
A projection (2D or 3D).
Settings for simulation object graphics and observer movement. VR-Forces includes the following observer modes:
Stealth. Stealth observer mode is a 3D projection configured for situational aware- ness.
Out-the-Window. Out-the-Window observer mode is configured for when you want to use VR-Forces as a desktop image generator. It hides many of the explana- tory visual effects present in the Stealth observer mode.
Plan View. The Plan View observer mode provides a 2D “big picture” view of the terrain.
XR. XR, or exaggerated reality, observer mode is a 3D mode that helps you under- stand the relationships between entities and the terrain when the observer is too far away from entities to view them at realistic sizes. It allows you to exaggerate entity size and terrain.
IR BlackHot (CameraFX). A view using the CameraFX IR (infrared) BlackHot sensor.
IR (CameraFX). A view using the CameraFX IR sensor.
NVG (CameraFX). A view using the CameraFX NVG (night vision goggles) sensor.
Camera (CameraFX). A view using the Visual Camera CameraFX sensor.
You can edit observer modes and add new ones. For details, please see “Creating and Editing Observer Modes,” on page 48-3.
When you change the observer mode, terrain may be displayed differently and the model sets used to display simulation objects may change. For descriptions of the observer modes, please see “Observer Modes,” on page 48-2.
To change the observer mode, choose Observer Set Observer Mode mode, or on the Observer Settings Toolbar (Figure 48-1), choose an option from the Observer Mode list.
Figure 48-1. Observer Settings Toolbar
VR-Forces comes with 3D and 2D observer modes. They are configured with the display settings, key mappings, and model sets that users most commonly want to use. However, if they do not meet your needs, you can easily edit them or create new observer modes.
The Observer and Observer Modes — Creating and Editing Observer Modes
To create an observer mode:
Choose Settings Display. The Display Settings dialog box opens.
Select the Observer Settings page (Figure 48-2).
Figure 48-2. Observer Settings page
Click the Add button ( ) to the right of the Observer Mode list. The Create New Observer Mode dialog box opens (Figure 48-3).
Figure 48-3. Create New Observer Mode dialog box
Type a name for the new observer mode.
Click OK.
In the Model Set list, select a model set.
Select a projection (2D or 3D).
Select the key map you want to use.
Optionally, specify a sensor mode.
Optionally, change the observer speed scaling settings and speed scaling mode.
Optionally, for 3D model sets, change the Model Scaling settings.
Enable or disable the mode-specific settings. The list of settings varies depending on the projection and model set.
To delete an observer mode:
Choose Settings Display. The Display Settings dialog box opens.
In the Observer Mode list, select the observer mode that you want to delete.
Click the Delete button ( ).
To edit an observer mode:
Choose Settings Display. The Display Settings dialog box opens.
In the Observer Mode list, select the observer mode that you want to edit.
Edit the attributes of the observer mode as desired.
To rename an observer mode:
Choose Settings Display. The Display Settings dialog box opens.
In the Observer Mode list, select the observer mode that you want to rename.
Click the Rename button ( ). The Rename Observer Mode dialog box opens.
Type the new name.
Click OK.
You can add and remove observers. Having multiple observers lets you assign different observers to different windows or channels. Changing the position and orientation of the observer in one channel does not affect the view of a different observer in a different channel. (For information about windows and channels, please see Chapter 77, Display Engine and Window Management.)
If you have multiple observers, the observer listed in the Observer Settings Toolbar is the observer assigned to the window that has focus. If you open the Display Engine Configuration Editor Panel and select a different observer in the Channel Attributes list, the data in relevant panels will change to reflect the values for the selected observer. However, as soon as you return focus to a window, the observer selection will change to match that of the window.
You can add observers in the Display Engine Configuration Editor Panel or on the Observer Settings page. (For information about the Display Configuration Editor Panel, please see Chapter 77, Display Engine and Window Management.)
If you want to save your observers, save the display engine configuration in which you created them. (Saving an observer just saves its name. It does not save any information about a particular observer mode or location that you may have used for that observer. To save location information, save an observer view.)
To add an observer on the Observer Settings page:
Choose Settings Display. The Display Settings dialog box opens.
Select the Observer Settings page (Figure 48-2).
Click the Add button ( ) to the right of the Observer list. The Create New Observer dialog box opens.
Type a name for the new observer.
Click OK. The new observer is added to the list.
To save the observer, save the display configuration. (Saving the observer settings does not save observers.) (For information saving a display configuration, please see “Saving a Display Engine Configuration,” on page 77-5.)
The Observer and Observer Modes — Adding an Observer
To add an observer on the Display Engine Configuration Editor Panel:
Choose View Display Engine Configuration Editor Panel. The Display Engine Configuration Editor Panel opens (Figure 48-4).
Select the channel on which you want to add an observer.
Click the Value field for the Observer Name attribute to make it editable.
In the list, select New (Figure 48-5).
Click Commit Changes. The Add Observer dialog box opens.
Type a name for the new observer.
Click OK. The new observer becomes the selected observer on the Observer Settings Toolbar, and is listed in the Observer Name attribute. (You may need to refresh the channel attributes before the observer name is listed.)
To save the observer, save the display configuration. (For information about saving a display configuration, please see “Saving a Display Engine Configuration,” on page 77-5.)
The Observer and Observer Modes — Removing an Observer
To remove an observer:
Choose Settings Display. The Display Settings dialog box opens.
In the Observer list, select the observer that you want to remove.
Click the Delete button ( ). The observer is removed.
If the observer was saved as part of a display configuration, save the updated display configuration.
The Observer and Observer Modes — Introduction to XR Mode
The Stealth observer mode (3D projection and 3D model set) provides situational awareness at the entity or small unit level. It is not ideal for getting the big picture of a simulation, because when you move the observer out to see large areas of terrain, the entity models, which are scaled to the terrain, are too small to see. The Plan View observer mode provides the big picture of a simulation, but does not provide situational awareness.
XR observer mode bridges the gap between the Stealth and Plan View observer modes. It is a 3D mode, so it provides situational awareness. However, it uses a special model set that makes models visible at greater distances than in Stealth observer mode. The 3D colorized model set shows entities as notional models using force coloring, which helps them stand out from the terrain. It also scales the model size to provided an exag- gerated reality (hence XR). (You can also scale the regular 3D model set if you want to.) Figure 48-6 illustrates model scaling with 3D colorized models.
Figure 48-6. Model scaling and colorized models
For details about scaling models, please see “Exaggerating the Scale of 3D Entity Models,” on page 19-23.
The Observer and Observer Modes — Communicating Information About the Observer
VR-Forces includes the following model sets:
3D Models. Realistic, 3D, textured models with articulated parts.
3D Colorized Models. 3D model caricatures with minimal articulation. These models do not have textures, they are solid colors, by force. You can change the coloring between primary colors and MIL-STD icon colors.
2D icons. MIL-STD 2525B icons.
You can use any of the model sets in both 3D and 2D views. In the 2D view, the 3D models can only be viewed from the top.
Each observer mode specifies a model set. You can change the model set associated with an observer mode by editing it (for details, please see “Editing an Observer Mode,” on page 48-5), but you can also dynamically change the model set being used.
To change the model set, choose Observer Set Model Set model_set, where
model_set is one of the options on the menu.
VR-Forces can transmit state updates describing the observer’s position and orientation, and can respond to view control messages sent by other applications.
By default, VR-Forces sends state update messages to make its state information known to other applications. This makes it possible for a plan view display to represent VR- Forces as an icon, or for one VR-Forces application to synchronize its observer move- ment with that of another VR-Forces application.
To enable or disable broadcasting of observer information, choose Settings
Publish Observers (or Stop Publishing Observers).
In DIS you can send observer information to just one other application, rather than to everyone in the exercise. To do this, on the Simulation Connections Configuration dialog box, instead of using a broadcast address, set the destination address to the address of a specific computer.
The Observer and Observer Modes — Displaying Models for Remote Observers
If an exercise includes stealth applications, and they are sending state updates, VR- Forces can detect them. A remote observer entity is listed in the object hierarchy, so you can attach the local observer to it just as you would attach to any other simulation object.
For related information, please see “Displaying Models for Remote Observers,” on page 48-12.
VR-Forces broadcasts the location and orientation of the observer. By default, it does not display a model for the observer. However, if there are other applications in an exer- cise that are broadcasting a stealth PDU (such as another VR-Forces), you might want to represent them with a model.
To display a model for remote observers:
Choose Settings Display. The Display Settings dialog box opens.
Select the Entity Display Settings page (Figure 48-7).
Select the Show Other Stealths check box.
This chapter explains how to move the observer (eyepoint) in the VR-Forces window. Moving the Observer 49-3
Using the Compass to View the Observer’s Heading 49-4
Editing the Compass’s Attributes 49-5
Observer Movement Functions and Keyboard Mappings 49-6
3D Observer Movement Coordinate Systems 49-7
2D Observer Coordinate System 49-7
The Attached Context and Observer Movement (3D Only) 49-8
Moving the Observer from the Keyboard in the 3D View 49-10
Moving the Observer Using the Mouse (3D View) 49-14
Changing the Observer’s Orientation with the Mouse 49-15
Orbiting the Terrain with the Mouse 49-15
Teleporting the Observer 49-16
Moving the Observer in the 2D View 49-16
Moving the Observer from the Keyboard in the 2D View 49-17
Moving the Observer Using the Mouse in the 2D Projection 49-18
Zooming the Observer in the 3D Projection 49-19
Zooming the Observer in the 2D Projection 49-20
Setting the Scale Factor for Paged LODs 49-20
Moving the Observer
Setting the Magnification LOD Angle for Paged LODs 49-21
Using the Depth of Field Effect 49-23
Configuring Depth of Field 49-25
Centering the Observer on a Simulation Object 49-26
Centering on an Object from the Object Console Summary Panel 49-26
Centering on an Object From an Information Panel 49-26
Simulating Camera Jitter 49-27
Forcing Orientation North 49-27
Enabling and Disabling View Constraints (3D Only) 49-28
Controlling Navigation Speed 49-28
Enabling or Disabling Speed Scaling 49-29
Changing the Observer’s Movement Speed 49-30
Saving and Recalling Views 49-30
Specifying the Startup View 49-32
Controlling the Observer from Other Applications 49-34
Enabling the Processing of View Control Messages 49-34
When you view a simulation, you usually want to move the observer (eyepoint) to different locations to view the terrain and scene elements being simulated. In VR- Forces, you can move the observer using the keyboard and the mouse. There are two basic contexts in which you can move the observer:
You can move it independently of any scene element. This is called absolute, or free-fly mode.
You can attach the observer to a simulation object, in which case it moves with the object. (You can also attach the observer to a prop. For details about attaching the observer to a simulation object or prop, please see Chapter 50, Attaching the Observer to Objects.)
Absolute mode and the various attachment types are collectively called attach modes.
In the 2D view, the Z coordinate is fixed. You can change the X and Y coordinates. You can change the observer’s yaw, but pitch and roll are fixed.
Y
Z
X X,Y
Yaw (heading) Pitch
Z
Roll
X,Y
The Observer Information Panel (Figure 49-4) displays the location and orientation of the observer in whichever coordinate system you select.
Moving the Observer — Moving the Observer
Figure 49-2. Observer Information Panel
VR-Forces can display a compass that always shows the heading of the observer. The compass is an observer mode setting. In Figure 49-3, the observer’s heading is approxi- mately Northwest.
To enable or disable the compass:
Choose Settings Display. The Display Settings dialog box opens.
Select the observer mode for which you want to change the compass setting.
In the list of observer settings, select or clear Compass.
i You can also enable or disable the compass by choosing Observer Compass.
You can configure the compass by editing its schema (ChannelCompass) and model definition (smallCompass and largeCompass). (For details about editing schemas, please see “Creating and Editing Schemas,” on page 81-4.)
By default, all channels have the largeCompass keyword. To change the style of compass used for a channel, change the keyword in the Keywords attribute for the channel. To completely remove the compass, delete the keyword. For details about setting channel attributes, please see “Changing a Channel’s Attributes,” on page 77-7.
You can change where the compass is displayed in the window by editing the location attribute. The permissible values are top, topRight, right, bottomRight, bottom, bottomLeft, left, and topLeft.
You can change the color of the compass by editing the darkTickColor and lightTick- Color attributes. The color is defined using the OpenGL scheme for specifying RGBA. The first three values are the RGB color values. The fourth value specifies opacity. Each value can be from 0.0 through 1.0.
When you move the observer, you are executing observer movement functions. An observer movement function is a specific way that the observer can move, such as Move Observer Forward or Move Level Observer Forward. (These functions both move the observer forward, but they use different observer coordinate systems. Observer move- ment coordinate systems are described in “3D Observer Movement Coordinate Systems,” on page 49-7.)
The various movement functions are mapped to the keys on the keyboard and to mouse buttons and the mouse wheel. If you use the default key mappings for the default observer modes, then most of the time, the observer will behave exactly as you would expect it to. However for some types of movement, such as forward and back, the observer can move differently depending on the view, the observer coordinate system, or the attach mode. Therefore, VR-Forces provides several key mappings that let you choose which type of observer movement to use. You can change these key mappings and create your own key mappings. (For details about editing key maps, please see .) This section describes how observer movement can vary based on the observer coordi- nate system and the attach mode.
Table 49-1 lists the observer modes and key map settings provided with VR-Forces.
Observer Mode | Projection | Key Map |
CameraFX modes | 3D | Observer Frame |
Stealth | 3D | Observer Frame |
XR | 3D | Observer Frame |
Plan View | 2D | 2D Level Observer Frame |
The observer modes all support the three model sets: 3D models, 3D colorized models, and 2D icons.
In the 3D view, the observer moves in the context of one of the following coordinate systems:
Level Observer Coordinates: Movement is with respect to the terrain. The level observer coordinate system is defined by the current up vector (Z), and a plane normal to that vector into which the observer's X and Y axes are projected. (Essen- tially, this means that the observer's heading is used while its pitch and roll are considered to be 0.0.)
Observer Coordinates: Movement is with respect to the observer's body coordinate system.
Entity Level Body Frame Coordinates: Movement is with respect to an entity’s body frame, but ignores pitch and roll.
Entity Body Frame Coordinates: Movement is with respect to an entity’s body frame, including pitch and roll.
The practical difference between observer coordinates and level observer coordinates is that in level observer coordinates, if you are looking down at the terrain, when you move forward and backward, you fly over the terrain, looking down. In observer coor- dinates, when you move forward and backward, you move down towards the terrain or away from it at whatever angle you are oriented towards it.
When you use the 2D view, the observer uses a variation of level observer coordinates. Movement is restricted to two dimensions, so there are no movement functions for changing the altitude, pitch, or roll. You can zoom in and out in the 2D view, but this does not change the observer’s altitude, it changes the field of view and resolution of the terrain image.
The Move Attached Context direction (forward, back, up, down, left, right) functions move the observer in the context of its attach mode. Movement is modified by attach modes in the following ways:
Follow mode: movement is in the entity’s level body frame.
Track mode: movement is in the entity’s level body frame.
Mimic mode: movement is in the entity’s body frame.
Tether mode: movement is in level observer frame.
Unattached: movement is in level observer coordinates.
Figure 49-4 and Figure 49-5 illustrate the differences between moving the observer in an attached context and without an attached context.
Figure 49-4 illustrates movement in entity level body coordinates (Follow and Track modes). The Move Observer Left function (A in Observer Frame key map) moves the observer to the left in observer coordinates, that is left relative to the observer’s heading. The Move Attached Context Left function (Shift + A) moves the observer left in the attached context. In entity level body frame, this means the observer moves left relative to the entity’s heading.
Start Move left Move left in entity level observer coordinates body frame coordinates
= Entity = Observer
Figure 49-4. Observer movement in entity level body frame coordinates
Figure 49-5 illustrates movement in entity body frame (Mimic mode). The Move Observer Left function moves the observer to the left in observer coordinates, that is left relative to the observer’s heading, but ignoring pitch and roll. The Move Attached Context Left function moves the observer left in the attached context. In entity body frame, this means the observer moves left relative to the entity’s heading and its pitch and roll.
Start Move left Move left in entity
in observer coordinates body frame coordinates
= Observer
Figure 49-5. Movement in entity body frame coordinates
VR-Forces maps the observer movement functions to the keyboard using key maps that support the most typical ways that users want to move through the 3D world, either in absolute mode or attached to a simulation object.
!
!
References to movement key combinations use the key mappings provided with VR-Forces. If you change these key mappings, the instructions may no longer be valid.
As described in “Moving the Observer,” on page 49-3, the observer typically moves with respect to the terrain in level observer coordinates or observer coordinates. The corresponding key maps are Level Observer Frame and Observer Frame.
Figure 49-6 illustrates the positional movement keys. Figure 49-7 illustrates the keypad layout for changing orientation and movement speed. For a complete list of movement functions and their keyboard and mouse mappings, please see VR-Forces Quick Reference Card or the Key Mapping Editor.
! To use the keypad for navigation, NumLock must be on.
1 2 3
Q W E
Up Fwd Down
A S D
Left Bkwd Right
Figure 49-6. Primary movement keys, observer coordinates (3D)
Linear 7+ 8 9
– Orbit
—
—
Speed
+
+
+
Speed
Pitch Roll
4 5 6
+ Orbit
Speed
Linear Speed
Heading
1—
Heading
2 3
Pitch Roll
Figure 49-7. Keypad layout, heading, pitch, and roll (3D)
If your keyboard does not have a keypad, as on most laptops, the Laptop key map lets you use the arrow keys to control the left, right, up, and down movement mapped to 4, 6, 8, and 2 on keypads.
To move the observer, press a key combination and hold it for as long as you want the observer to keep moving.
You can press more than one key at a time to combine movement functions. For example, pressing the move forward and move left keys at the same time moves the observer diagonally left and forward.
This section lists the different ways that you can move the observer using the keyboard. For a complete list of movement functions and their keyboard and mouse mappings, please see VR-Forces Quick Reference Card. You can:
Move forward and backward (observer, level observer, entity, level entity, and attached context coordinates).
Move up and down (observer, level observer, entity, level entity, and attached context coordinates).
Move left and right (observer, level observer, entity, level entity, and attached context coordinates).
Rotate (heading) left and right (observer and level observer coordinates).
Rotate (pitch) up and down (observer and level observer coordinates).
Rotate (roll) left and right (observer and level observer coordinates).
Orbit left and right.
Orbit up and down.
Look (move camera) left and right.
Look (move camera) up and down.
Tilt (move camera) left and right.
Reset the observer to the default position and orientation for the attached mode.
Reset the camera to the default position and orientation.
Zoom the view.
For details about orbiting, please see “Orbiting,” on page 49-13. For details about moving the camera, please see “Moving the Camera,” on page 49-13.
When you view a geocentric terrain and move the observer more than 6 million meters away from the earth’s surface, the view is forced to focus toward the center of the earth. The practical effect of this mode is that the left and right movement keys orbit the eyepoint around the earth, rather than moving the entire earth to the left or right.
To orbit around an object:
Attach the observer to the object.
Press the right or left arrow keys.
To orbit around a point:
If you are attached to a simulation object, detach (press z).
Press the right or left arrow keys.
By default, the observer always looks in the same direction as its heading. However, just as the turret on a tank can swivel and fire in directions other than its body’s heading, the observer can look in a direction other than its heading. The ability to look around is enabled in the camera. You can move the observer’s camera up, down, left, right, tilt left, and tilt right. (The default key mappings are Ctrl + Keypad number, where number is 2, 3, 4, 6, 8, or 9.)
! To use the keypad for navigation, NumLock must be on.
You can tell that the camera is moving, but the heading is not, by observing the compass. If you change the heading, the view of the terrain changes and the compass moves. If you move the camera, but keep the heading static, the view of the terrain changes, but the compass does not move.
To move the camera, press the keys mapped to the camera movement functions.
Moving the Observer — Moving the Observer Using the Mouse (3D View)
Using the mouse, you can:
Drag the terrain.
Drag the view.
Orbit the terrain.
Change orientation.
Teleport (jump).
Dragging the terrain combines the move forward, backward, left, and right functions.
To drag the terrain:
Click a point on the terrain and hold down the left mouse button.
Drag the mouse left, right, forward, and backward.
Dragging the terrain is most effective when you are moving large distances, such as several kilometers. To move small distances, use the keyboard.
Moving the Observer — Moving the Observer Using the Mouse (3D View)
To disable terrain dragging, on the Observer Control Panel, clear the Allow Terrain Dragging check box (Figure 49-8).
Figure 49-8. Observer Control Panel
To change the observer’s orientation, hold down the right mouse button and drag the mouse. The observer rotates in the direction you drag the mouse.
Dragging the view combines the observer up, down, left, and right movement func- tions. Unlike dragging the terrain, which requires you to click a point on the terrain, you can drag the view from any observer location.
To drag the view, hold down the middle mouse button (or wheel) and drag the mouse.
To orbit the terrain with the mouse, press Ctrl and drag the mouse.
Moving the Observer — Moving the Observer in the 2D View
To teleport the observer:
Shift+click on the terrain or prop that you want to jump to.
If you Shift+click on a filled area, the observer attaches to the area; it does not teleport. If you want to teleport to the terrain under an area, hide the area first. You can hide an area by hiding all tactical graphics or hiding the overlay on which the area is located.
Ctrl+Shift+click on the simulation object that you want to jump to.
In the 2D view, you move the observer using the mouse and keyboard just as you do in the 3D view. Many of the key and button mappings for the 2D view are the same as those in the 3D view. However, the 2D mappings do not support movement that is not meaningful in two dimensions, such as up and down (altitude), pitch, and roll.
When Orient North is enabled, you cannot change the heading of the observer. For information about Orient North, please see “Forcing Orientation North,” on page 49-27.
Moving the Observer — Moving the Observer in the 2D View
Figure 49-9 illustrates the positional movement keys for the 2D view. Figure 49-10 illustrates the keypad layout for changing heading and movement speed. For a complete list of movement functions and their keyboard and mouse mappings, please see VR- Forces Quick Reference Card.
! To use the keypad for navigation, NumLock must be on.
1 2 3
Q W E
Zoom Up Out
Zoom In
A S D
Left Down Right
Figure 49-9. Primary movement keys, observer coordinates (2D)
+
+
Linear 7 8 9
Speed Up
– Orbit
—
—
Speed
+
+
+
4 5 6
+ Orbit
Speed
Linear Speed
Left
1—
Right
2 3
Down
Figure 49-10. Keypad layout, heading, pitch, and roll (2D)
You can change the observer’s position and heading with the mouse. You can change the observer’s position by dragging the terrain, as described in “Dragging the Terrain,” on page 49-14. You can change heading by orbiting, as described in the next section. (To see the full list of mouse mappings, view the Mouse Mappings page on the Applica- tion Settings dialog box.)
When Orient North is enabled, you cannot orbit. For information about Orient North, please see “Forcing Orientation North,” on page 49-27.
To orbit the terrain with the mouse, press the right mouse button and drag the mouse.
You can zoom the observer in the 3D and 2D projections. Although the apparent effect is similar for top-down views, they are conceptually and behaviorally different. In addi- tion to a straight “in-and-out” zoom, you can zoom the view to the extents of a simula- tion object or group of simulation objects.
If you want to see something at a higher level of detail without moving the observer, you can zoom the observer view. Zooming the observer narrows the field of view and magnifies objects in the view. The magnification level is saved in saved views. 3D zoom has the following characteristics:
When you zoom the observer view, its movement and mouse look speeds are decreased as the magnification increases, to allow for increased control.
When you switch between 3D and 2D, VR-Forces calculates a 2D zoom level to match the 3D view. If you then switch back to 3D, it remembers the observer loca- tion and zoom level.
If you zoom in from a very high altitude there may be scene corruption due to insufficient precision in the z-buffer. This can be limited by moving the observer closer to the subject before zooming in. This issue is typically only encountered above 10,000 meters.
When you zoom, VR-Forces respects the environmental conditions at the observer’s location. For example, if the observer is above the cloud layer, zooming does not let you see below the clouds. Or, if it is raining at the observer’s location, the visibility will not improve as you zoom in on a distant object.
After zooming in, when you zoom out, you can only zoom out to the 0 magnifica- tion level. That is, you can only zoom out back to the observer’s location. If you want to see more of the terrain, you must move the observer to a greater distance from the terrain.
To zoom in, press the = key, press Ctrl and scroll the mouse wheel forward, or on the Observer Control Panel specify a value in the Magnification box.
To zoom out, press the - (dash) key, press Ctrl and scroll the mouse wheel back- ward, or on the Observer Control Panel specify a value in the Magnification box.
Each press of the = or - key, or increment of the mouse wheel, increases or decreases magnification by a factor of 1.25.
To reset magnification to 1.0, press zero (0) or press the middle mouse button.
In the 2D projection you can zoom the observer view closer to and away from the terrain. However, unlike in 3D, in which you cannot zoom out past the location of the observer, there is essentially no limit on zooming in and out because in 2D, the observer does not actually have altitude.
To zoom in, press e, scroll the mouse wheel forward, or to step the zoom, press the
= key.
To zoom out, press q, scroll the mouse wheel backward, or to step the zoom, press the - (dash) key.
To reset the observer to the default zoom level, press the Space bar.
To set the scale factor for paged LODs:
Choose Settings Experimental Features. The Experimental Features dialog box opens.
Adjust the Paged LOD Magnification Scale Factor slider.
When the observer zooms in, VR-Forces pages in higher LOD tiles for the terrain. This increases memory usage. You can tune performance by restricting high LOD tiles to the areas you are interested in and using lower LOD tiles for the rest of the terrain. The Paged LOD Magnification LOD Angle setting lets you adjust the angle within which higher LOD tiles are used (Figure 49-11).
Magnification LOD Angle
Higher LOD
Lower LOD
Figure 49-11. Paged LOD magnification LOD angle
If you want the observer to be able to quickly scan a wide angle of terrain, you should increase the magnification LOD angle or you may have to wait for high LOD tiles to page in as you move the observer.
On some terrains, when high LOD tiles are adjacent to low LOD tiles, there can be cracks in the terrain along the boundaries. If you experience this problem, increase the magnification LOD angle.
This setting is saved when you close VR-Forces.
To set the magnification LOD angle for paged LODs:
Choose Settings Experimental Features. The Experimental Features dialog box opens.
Adjust the Paged LOD Magnification LOD Angle slider.
If no simulation objects are selected and the observer is not attached to a simula- tion object, the observer view is reset to the terrain center. This is the same behavior as pressing Space bar.
If the observer is attached to a simulation object, the observer resets to the default attached view. This is the same behavior as pressing Space bar.
If simulation objects are selected and the observer is not attached to a simulation object, the observer view is redisplayed to show the extents of the selected simula- tion objects. In the 3D view, this is a top-down view.
To zoom the observer to the extents of selected simulation objects:
Select the simulation objects that you want to zoom in on. To zoom to the extents of all simulation objects, do not select any simulation objects.
Choose View Zoom to Extents.
You can configure a scenario so that it zooms to the extents of all simulation objects when the scenario loads. This can be convenient when you have simulation objects located in one part of a large terrain.
If a scenario has a saved observer view that is designated as the initial view for the scenario, it overrides Zoom to Scenario Extents on Load.
To zoom to simulation object extents when a scenario loads:
Open the scenario that you want to zoom to extents on load.
Choose Settings Application. The Application Settings dialog box opens.
Select the Zoom to Scenario Extents on Load check box.
Save the scenario. The next time you load the scenario, if the Zoom to Scenario Extents on Load check box is selected, it will zoom to the entity extents.
In Figure 49-12, the focal depth is about 10 meters, fairly close to the observer, and the focal range is also small, so that the scene is out of focus just past the car (note that the first large tree is out of focus). In Figure 49-13, the focal depth is the same, but the range is much greater, so the scene is in focus to the back of the parking lot.
In Figure 49-14 the focal depth is centered at the second large tree. The focal range is, again, fairly narrow, so that the person and car in the foreground are out of focus.
VR-Forces lets you set the focal depth automatically or manually. In either case, you can adjust the focal range.
Figure 49-12. Depth of field (close)
Moving the Observer — Using the Depth of Field Effect
Figure 49-13. Depth of field (far)
Figure 49-14. Depth of field, middle distance
To enable depth of field:
Choose Settings Display. The Display Settings dialog box opens.
Select the observer mode for which you want to enable depth of field.
Select or clear the Depth of Field check box.
You can also enable or disable depth of field by choosing Observer Depth of Field.
To configure depth of field:
Choose Settings Display. The Display Settings dialog box opens.
Select the Render Settings page (Figure 49-15).
To use autofocus for focal depth, select the Use Autofocus for Depth of Field check box.
To set the focal depth manually, clear the Use Autofocus for Depth of Field check box and adjust the Focus Distance slider or specify a value in the box.
To adjust the focal range, adjust the Depth of Field slider or specify a value in the box.
Moving the Observer — Centering the Observer on a Simulation Object
You can center the observer on a simulation object from the Object Console Summary Panel, the Last Clicked Object Panel, or the Information dialog box. If you center on a simulation object from the Object Console Summary Panel, the observer gets attached to the object. It does not get attached using the other methods.
If you see that there is a message in the Object Console Summary Panel regarding a simulation object, you may want to quickly view that object. The Object Console Summary Panel lets you center the view on a simulation object. When you center the observer view on a simulation object, the observer attaches to it in Tether mode. For details about Tether mode, please see “Tether Mode,” on page 50-12.
To center the observer on a simulation object:
In the Object Console Summary Panel, right-click a message from the simulation object you want to center on. A menu is displayed.
Choose Center Entity.
If you center on a simulation object in Plan View observer mode, the icon is centered in the window. If you center on a simulation object in Stealth observer mode, the observer stays in the current orientation relative to the centered object. If you press the Spacebar, the view changes to a top down view, similar to Plan View mode.
If the observer is attached to a simulation object, you cannot center the observer on a different object using this procedure.
Figure 49-16. Simulation object icon
Moving the Observer — Forcing Orientation North
To simulate camera jitter:
Choose Settings Display. The Display Settings dialog box opens.
In the Camera Shake section, select Allow Camera Shake.
Optionally, adjust the Intensity slider or change the value in the box.
In the 2D view, by default the observer’s heading is forced to stay North (up), regardless of the heading of the simulation object to which it is attached. You can disable this setting, in which case if you attach to a simulation object, the view of the terrain rotates to match the heading of the attached simulation object.
Figure 49-17 illustrates the view when the observer is attached to an entity with orien- tation forced to North or matched to that of the entity.
Orient North Orient to entity heading Figure 49-17. Forcing orientation North
To enable or disable a northward orientation:
Choose Settings Display. The Display Settings dialog box opens.
In the Observer Mode list, select Plan View.
In the list of observer settings, select or clear Orient North.
You can also enable or disable northward orientation by choosing Observer Orient North.
Moving the Observer — Enabling and Disabling View Constraints (3D Only)
If view constraints are enabled, you may not be able to move the observer into buildings to view and place entities. Changing the near clipping plane or transparency will let you see through walls, but in constrained mode, you will still not be able to move the observer through the walls.
To enable or disable view constraints, use one of the following methods:
Press / (forward slash).
Choose Observer Constrain to Terrain.
On the Observer Control Panel (Figure 49-8), select or clear the Terrain Constrained check box.
Set the navigation speed manually. The observer always moves at the specified speed.
Use speed scaling to automatically move at different speeds under different circum- stances. You can change the rate at which speed is scaled.
In either case, the controls for changing speed are the same. Their effect varies depending on whether or not speed scaling is enabled.
Moving the Observer — Controlling Navigation Speed
When speed scaling is enabled, VR-Forces makes the following assumptions:
If the observer is unattached, the higher above the terrain it is, the faster you want to move.
The closer you are to an attached object, the more slowly you want to move.
To enable or disable speed scaling, use any of the following methods:
On the Observer Control Panel (Figure 49-8), select or clear the Scaled Speed check box.
Press the multiply key (*) (not the asterisk key).
When speed scaling is enabled, VR-Forces scales observer speed based on the its height above the terrain. Even if the observer is higher than all terrain points, speed can still be affected if there are changes to the terrain, such as mountains. This can be annoying if it happens unexpectedly. Therefore, you can choose to base speed scaling on height above ground level, or height above mean sea level. In that latter case, changes to the terrain would not affect the speed at which the observer moves. If you set speed scaling to use height above mean sea level, you can specify an offset.
To set the speed scaling mode, use one of the following methods:
On the Observer Control Panel (Figure 49-8), set the Speed Scaling Mode to Above Ground Level (AGL) or Above Mean Sea Level (MSL)
On the Display Settings dialog box, Observer Settings page, set the Speed Scaling Mode to Above Ground Level (AGL) or Above Mean Sea Level (MSL)
You can change the observer’s linear, rotational, and orbital speed. If speed scaling is enabled, these controls change the speed gain. If speed scaling is disabled, the controls change the absolute speed.
To change the observer’s speed, use any of the following methods:
Adjust one of the Observer Speed sliders on the Observer Control Panel (Figure 49-8) or on the Observer Settings page on the Display Settings dialog box. The default (center of the slider) is 1. The range is 0.1 to 10.
Press one of the following keys to change linear speed:
Keypad 7 (faster) or 1 (slower).
Ctrl + mouse wheel forward or back.
Movement key + mouse wheel forward or back.
Press Keypad + (faster) or - (slower) to change orbital speed.
When you change the observer’s speed using the keyboard or mouse, if the Observer Control Panel or the Observer Settings page is open, you can see the scale slider moving to the new setting.
At any given moment, the state of the observer is called its view. You can capture views so that you can quickly return to them. You can also save them for future use. VR- Forces automatically saves observer views as part of the scenario (scenario_name.osrx). You can also save views independently of scenarios. The procedures in this section describe that process.
If the observer is not attached to a simulation object, its view is its position and orienta- tion in the simulated environment. If the observer is attached to a simulation object, a view saves the following information:
Attach mode.
Positional offset.
Marking text.
When you save a view in the 2D view, the X and Y values are saved. The zoom level is not saved.
Saved views are managed in the Observer Views Panel (Figure 49-18).
Figure 49-18. Observer Views Panel
Its buttons have the following meanings:
Save the current view.
Mark view to load on scenario startup.
Delete the selected view.
Save all views to a file.
Save the selected view to a file.
Load a saved views file and append it to the list.
Load a saved views file and replace the current list.
Clear the list.
Saved views are keyed to the marking text of the object to which the observer is attached.
Choose View Observer Views Panel. The Observer Views Panel opens (Figure 49-18).
Click the Add button ( ). The current view is added to the list.
To recall a view, select it in the Observer Views Panel. The view changes immedi- ately.
Normally, when you select an observer view, the observer jumps immediately to the new view. However, VR-Forces can smoothly transition from the current observer view to a saved view.
To transition between observer views, hold down the Ctrl key and click the view in the Observer Views Panel that you want the observer to move to.
If the observer view that you select uses a different observer mode (for example, from PVD mode to Stealth), VR-Forces does not change the observer mode. The view moves to an approximation of the the desired view in the current observer mode.
To delete a view:
In the Observer Views Panel, select the view you want to delete.
Click the Delete button ( ).
To remove all views from the list, in the Observer Views Panel, click the Clear List button ( ).
If a scenario has observer views, you can specify that one of them be the view selected when the scenario loads. (The observer view does not get selected when you rewind a scenario.)
To specify a view as the startup view:
Select the view.
Click the star button ( ) on the Observer Views Panel.
You can save views to a file independently of the scenario and load them at a later time. You can save an individual view or all of the views in the list.
The default location for saved views is ./appData/settings/vrfGui.
To save the selected view to a file:
In the Observer Views Panel, click the Save Individual View button ( ). The Save Selected Observer dialog box opens.
Select the file to which you want to save the view, or type the name of a new file.
Click OK.
To save all views to a file:
In the Observer Views Panel, click the Save All Views button 
). The Save Observer Views dialog box opens.
Select the file to which you want to save the views, or type the name of a new file.
Click OK.
To load views and append them to the list of views:
In the Observer Views Panel (Figure 49-18), click the Load Views and Merge button ( ). The Open Observer Views dialog box opens.
Select the saved views file that you want to load.
Click OK.
To load views and replace the list of views:
In the Observer Views Panel, click the Load Views and Replace button ( ). The Open Observer Views dialog box opens.
Select the saved views file that you want to load.
Click OK.
Moving the Observer — Controlling the Observer from Other Applications
Set the observer’s position and orientation. Acceptance of view control messages is a global setting.
The view control PDUs are experimental, and are not an official part of DIS. They are of PDU kind 202.
To enable or disable the processing of view control messages, choose Settings View Controls, or click the View Control button ( ) on the Display Settings Toolbar.
50. Attaching the Observer to Objects
This chapter describes attachment modes and how to attach the observer to simulation objects and props.
Attaching the Observer to a Simulation Object or Prop 50-2
Attaching the Observer to Another Observer 50-4
Attaching to an Articulated Part 50-4
Attaching the Observer in Mimic Track or Tether Track Mode 50-4
Attaching the Observer in Mimic Location Track or Tether Location Track Mode 50-5
Filtering the Object Attachment List 50-5
Detaching from a Simulation Object 50-5
Hiding the Attached Model (3D Projection Only) 50-6
Improving Performance when Attaching to Ground Objects 50-6
Attach Modes in the 3D View 50-7
Mimic Location Track Mode 50-10
Tether Location Track Mode 50-13
Attach Modes in the 2D View 50-15
Attaching the Observer at Startup 50-15
This procedure applies to Follow, Tether, Track, Mimic, and Space Follow modes. To attach in Tether Track or Mimic Track mode, please see “Attaching the Observer in Mimic Track or Tether Track Mode,” on
page 50-4. To attach in Tether Location Track or Mimic Location Track mode, please see “Attaching the Observer in Mimic Location Track or Tether Location Track Mode,” on page 50-5.
To attach the observer to a simulation object or prop, do one of the following:
Right-click an object in the Objects List Panel (Figure 50-1) or on the terrain and select Observer Attach mode, where mode is one of the supported attach modes. (For details about attach modes, please see “Attach Modes in the 3D View,” on page 50-7 and “Attach Modes in the 2D View,” on page 50-15.)
Select a simulation object or prop. (For details about selecting simulation objects and props, please see “Selecting Simulation Objects, Tactical Graphics, and Props,” on page 17-4.) On the Attachments Panel (Figure 50-2), or on the Attach Object Toolbar (Figure 50-3), click the Attach button 
) to attach with the current attachment mode.
Figure 50-2. Attachments Panel
Figure 50-3. Attach Object Toolbar
On the Attachments Panel or Attach Object Toolbar, click the next or previous arrows to attach to the next (or previous) object in the object list.
Shift+click the object you want to attach to.
Press greater than (>) to attach to the next simulation object or prop in the object list without regard to the attachment filter. Press less than (<) to attach to the previous object.
Press period (.) to attach to the next simulation object or prop allowed by the attachment filter. Press comma (,) to attach to the previous object.
You can attach observers to other observers if you have more than one window open.
To attach an observer to another observer:
Filter the Objects List to show All objects or to show observers.
Select the window whose observer you want to attach to another observer.
In the Objects List, select the observer you want to attach to.
Right-click and select Observer Attach mode, where mode is one of the supported attach modes.
To attach to an articulated part:
Attach the observer to an entity, as described in “Attaching the Observer to a Simu- lation Object or Prop,” on page 50-2.
On the Attachments Panel (Figure 50-2), click the down arrow. The Attachments Panel expands.
In the Articulated Parts list, select the part to which you want to attach the observer.
To attach the observer in Tether Track and Mimic Track modes, you must specify a primary simulation object and a secondary simulation object (the tracked simulation object).
To attach the observer in Mimic Track mode or Tether Track mode:
Right-click the primary simulation object in the Objects List Panel or in the window. A popup menu is displayed.
Choose Observer Attach Attach Mimic Track (or Attach Tether Track). The cursor changes to show an arrow and a Plus sign.
Click the secondary simulation object in the Objects List or in the window.
To attach the observer in Tether Location Track and Mimic Location Track modes, you must specify a primary simulation object and a location.
To attach the observer in Mimic Location Track mode or Tether Location Track mode:
Right-click the primary simulation object in the Objects List Panel or in the window. A popup menu is displayed.
Choose Attach Mimic Location Track or Attach Tether Location Track. The cursor changes to show an arrow and a Plus sign.
Click a location in the display window.
Although you can attach the observer to simulation objects and props, it is likely that at any given time you will only want to attach to one type of object (usually simulation objects). To reduce the number of objects that you have to iterate through when using Attachments Panel arrows to pick the next or previous object, you can filter the attach- ment list.
The filter for buoys and beacons applies to S-57 feature data, not buoys that are simulation objects, such as sonobuoys.
To filter the attachment list:
On the Attachments Panel (Figure 50-2), click the down arrow. The Attachments Panel expands.
In the Attachment Filter list, select the type of scene element that you want to attach to.
To detach the observer from the simulation object to which it is attached, on the Attachments Panel (Figure 50-2), click the Detach button ( ), or press z.
You can hide the model for the simulation object to which the observer is attached.
To hide the attached model:
On the Attachments Panel (Figure 50-2), click the down arrow. The Attachments Panel expands.
Select the Hide Attached Model check box.
Since props do not move, attaching the observer to a prop does not result in any observer movement. The principal benefit of attaching to a prop is to let you quickly refocus the observer on a particular location in the scene. If you attach in Track mode, using the keyboard movement keys allows you to orbit around the prop.
When the observer is attached to air entities, Z-fighting can affect visual quality. To prevent this problem, VR-Forces needs to calculate the entity’s height above the terrain. However, the calculation can affect performance. Unfortunately, when this calculation is enabled (the default), it must be applied to all entity types. If you know that you will want to attach the observer to ground simulation objects, but not air simulation objects (or if you do not care about Z-fighting), you can disable the height above terrain calcu- lation, which may improve performance when the observer is attached to simulation objects. To disable the height above terrain calculation, start VR-Forces with the
-S | --suppressHatIntersectOnAttach command line option.
Attach modes are combinations of position and orientation models and constraints that produce a useful behavior for the observer. Except for Absolute mode, attach modes describe how movement of the simulation object to which the observer is attached affects the position and orientation of the observer.
VR-Forces supports the following attach modes:
Absolute: The observer is not attached to a simulation object; it moves in space independently of all simulation objects.
Follow: The observer position and heading changes with the simulation object’s position and heading.
Mimic: The observer position and orientation changes with the simulation object’s position and orientation.
Mimic Track: The observer’s position changes with the simulation object’s position while its orientation is focused on a second entity.
Mimic Location Track: The observer’s position changes with the simulation object’s position while its orientation is focused on a location.
Space Follow: The observer is a fixed distance from the simulation object and the simulation object model is scaled to be observable from a great distance.
Tether: The observer’s position changes with the simulation object’s position.
Tether Track: The observer’s position changes with the simulation object’s position while its heading is focused on a second simulation object.
Tether Location Track: The observer’s position changes with the simulation object’s position while its heading is focused on a location.
Track: The observer’s heading changes to track the simulation object’s position and heading.
The attach modes are described in detail in the following sections. For details about how to attach the observer to a simulation object, please see “Attaching the Observer to a Simulation Object or Prop,” on page 50-2.
In Follow mode, the observer maintains its relationship to the simulation object as follows:
When the simulation object’s position changes, the observer’s position changes to maintain its offset.
When the simulation object’s heading changes, the observer’s heading and position change to maintain the offset.
When the simulation object’s pitch or roll change, the observer pitch and roll do not change.
Figure 50-4 illustrates the characteristics of Follow mode.
Position Heading Pitch and roll
= Entity = Observer
In Mimic mode, the observer behaves as though it is rigidly connected to the entity. Use Mimic mode to create the effect of riding in a vehicle cockpit, or of following a vehicle from an external location while connected to it by a solid, invisible rod. The observer maintains its relationship to the simulation object is as follows:
When the simulation object’s position changes, the observer’s position changes to maintain its offset.
When the simulation object’s heading changes, the observer’s heading and position change to maintain the offset.
When the simulation object’s pitch or roll change, the observer’s pitch and roll change and the observer’s position changes to maintain its offset.
When cockpit displays are enabled, you cannot change the position or orientation of the observer relative to the entity.
Figure 50-5 illustrates the characteristics of Mimic mode.
Position Heading Pitch and roll
= Entity 
= Observer
Mimic Track mode combines Mimic mode and Track mode. The observer’s position changes with that of the entity to which it is attached, as in Mimic mode, while its orientation changes to remain focused on a secondary, tracked entity.
Orientation controls are disabled.
Figure 50-6 illustrates the characteristics of Mimic Track mode.
Secondary attachment
Secondary attached entity
Primary attached entity
= Entity = Observer
Mimic Location Track mode works like Mimic Track mode except it tracks a location on the ground rather than an entity.
Space Follow mode attaches the observer above an entity, looking down at it. Although it can be used with any entity, its primary purpose is for attaching to space objects such as satellites. You can also usefully use it with fixed-wing and rotary-wing entities.
The observer is attached at a fixed distance, determined by the near clipping plane for the object. For a satellite, this distance is approximately 500,000 meters. Since it is not possible to see regular models at that distance, the attached object is scaled to be visible. (You cannot change the scaling of the attached object.) Other objects are not scaled (except to the extent that model scaling might be enabled).
The observer maintains its relationship to the simulation object as follows:
When the simulation object’s position changes, the observer’s position changes to maintain its offset.
When the simulation object’s heading changes, the observer’s heading changes.
When the simulation object’s pitch or roll changes, the observer’s pitch or roll does not change.
You cannot move the observer towards or away from the simulation object. You can rotate the observer around the entity, but you cannot go below the horizontal plane of the entity.
Figure 50-7 illustrates the characteristics of Space Follow mode.
Position Observer Rotation
= Entity 
= Observer
Figure 50-7. Space Follow mode
When the simulation object’s position changes, the observer’s position changes to maintain its offset.
When the simulation object’s heading changes, the observer’s heading does not change.
When the simulation object’s pitch or roll change, the observer’s pitch and roll do not change.
Figure 50-8 illustrates the characteristics of Tether mode.
Position Heading Pitch and roll
= Entity = Observer
Tether Track mode combines Tether mode and Track mode. The observer’s position changes with that of the entity to which it is attached, as in Tether mode, while its orientation changes to remain focused on a secondary, tracked entity.
Orientation controls are disabled.
Figure 50-9 illustrates the characteristics of Tether Track mode.
Primary attachment Secondary attachment
Secondary attached entity
Primary attached entity
= Entity 
= Observer
Figure 50-9. Tether Track mode
When the simulation object’s position changes, the observer’s heading changes to keep the entity centered in the observer’s view; the observer’s position does not change.
When the simulation object’s heading changes, the observer’s heading does not change.
When the simulation object’s pitch or roll change, the observer’s pitch and roll do not change.
Figure 50-10 illustrates the characteristics of Track mode.
Position and heading Pitch and roll 
= Entity = Observer
Attaching the Observer to Objects — Attaching the Observer at Startup
The 2D view supports Follow mode and Tether mode. In Follow mode, the heading of the observer changes with the entity (if Orient North is disabled); in Tether mode, it does not. You can use the standard movement keys (w, a, s, d) to offset the observer with respect to the simulation object's position. You can use the orbit keys (left arrow, right arrow) to offset the observer's orientation with respect to the entity's orientation (in Follow mode) or the terrain.
If the observer is attached to an entity in the 3D view and you switch to the 2D view, the attach mode is mapped to either Follow or Tether modes, as shown in Table 50-1. If you then switch back to the 3D view the original attach mode is restored.
Table 50-1: 3D to 2D attachment mode mapping
3D Attach Mode 2D Attach Mode
3D Attach Mode 2D Attach Mode
Follow Follow
Mimic Follow
Mimic Track Follow Mimic Location Track Follow Space Follow Follow
Tether Tether
Tether Track Tether Tether Location Track Tether Track Tether
To attach the observer to an entity when you load a scenario, save a view and specify it as a favorite, as described in “Specifying the Startup View,” on page 49-32.
Attaching the Observer to Objects — Attaching the Observer at Startup
51. Inset Views, Sensor FOVs, and HUDs
This chapter describes several kinds of special secondary windows plus head up displays.
Displaying Cockpit Displays (3D Only) 51-3
Displaying Instrument Panels 51-6
Configuring Entities to Use Instrument Panels 51-7
Displaying Sensor Views (3D Only) 51-8
Displaying a Sensor Field of View Cone 51-9
Controlling the Sensor View 51-10
Inset Views, Sensor FOVs, and HUDs — Inset Views
You can display inset views of individual simulation objects. Figure 51-1 shows a heli- copter hovering over the Ala Moana area in the MAK Earth (online).mtf terrain with an inset view of a car driving through the town.
!
!
By default, when you create an inset view, the observer in the inset view is attached to the simulation object in Mimic mode. This has the side effect of causing the 3D model in the main window to disappear. (The reverse occurs if you attach the observer in the main window to the simulation object in Mimic mode.) To make the model reappear, select the inset view and change the attach mode or detach the observer.
You can change the observer position and orientation in an inset view using keyboard controls. You can also edit window and channel properties for the window in the Display Engine Configuration Editor. (For information about the Display Engine Configuration Editor, please see Chapter 77, Display Engine and Window Management.)
When you create an inset view, the title bar contains the simulation object’s name. However, the window is not actually tied to the simulation object and you can change the view in the inset view and view other simulation objects. The title bar will continue to display the name of the simulation object for which the window was created.
To open an inset view:
Right-click a simulation object (or its entry in the Objects List Panel). A menu opens.
On the menu, choose Create Inset View.
VR-Forces can display cockpit displays created with GL Studio. It includes cockpits for fixed-wing, rotary-wing, and ground vehicle entities. As with other entity effects, cock- pits have schemas and model definitions that you map to entity types. For details about cockpit display models, please see “Adding New Cockpit Display Models,” on
page 83-10.
VR-Forces supports 2D cockpits (Figure 51-2) and 3D cockpits (Figure 51-3). A 2D cockpit is fixed to the center of the screen and you cannot zoom in or out on the instru- ment panel. A 3D cockpit is aligned with the front of the vehicle. If you move the eyepoint, the instrument panel moves in or out of view as you would expect. You can zoom in and out on the instruments.
Inset Views, Sensor FOVs, and HUDs — Displaying Cockpit Displays (3D Only)
Cockpits are displayed only when the observer is attached to an entity in Mimic mode.
VR-Forces includes one 3D cockpit, for the F-16 fighter jet.
Cockpits are not supported on Linux.
To display cockpits:
Choose Settings Display. The Display Settings dialog box opens.
Select the Cockpit Display Settings page (Figure 51-4).
To enable or disable cockpit displays, select or clear the Enable Cockpit Display check box.
Attach the observer to an entity in Mimic mode.
You can also enable and disable cockpit displays by choosing Settings Cockpit Displays or by clicking the Cockpit Displays button ( ) on the Display Settings Toolbar.
Inset Views, Sensor FOVs, and HUDs — Displaying Instrument Panels
Instrument panels are inset windows that display a vehicle instrument such as an altim- eter or artificial horizon. Unlike a cockpit display, which is a fixed display that operates in Mimic mode, an instrument panel is an independent window (like an inset view) that you can place anywhere on the screen (Figure 51-5). It does not affect the observer mode. You can organize multiple instrument panels to create your own virtual cockpit.
Figure 51-5. Instrument panels
When you create an instrument panel, the title bar of the window lists the entity for which you created it.
i Instrument panels are GL Studio controls.
Instrument panels are not supported on Linux.
If the source of the instrument panel is removed from the exercise, for example when a Logger recording rewinds, the instrument panels are removed from the inset windows. To see them again you must open new instrument panels. Because the relationship between an instrument panel window and an entity is not persistent across multiple runs of an exercise, you cannot save an instrument panel layout for an entity. (You could save the layout of the windows to a display configuration, but they would not display instrument panels when you loaded the configuration.)
If you want to put multiple instrument panels in one window, like the six-pack panel provided with VR-Forces, you must use GL-Studio.
Inset Views, Sensor FOVs, and HUDs — Displaying Instrument Panels
To open an instrument panel:
Select the entity for which you want to display an instrument panel.
On its right-click menu, choose Create Instrument Panel. A submenu is displayed.
Choose the instrument panel you want to open.
VR-Forces includes a set of instrument panels for fixed-wing aircraft, although many of them may be appropriate for rotary-wing aircraft, and even for ground vehicles. (For example, you might want to show a compass for a ground vehicle to get its heading or an altimeter to show its height above sea level.) The availability of instrument panels to an entity is determined by the instrumentPanelCategory parameter in its model definition.
The instrument panels provided with VR-Forces have the instrumentPanelCategory set to FixedWing. All fixed-wing entities have this parameter set in their model definition.
None of the other entities do. If you want other entities to display instrument panels provided with VR-Forces, you can add this parameter to their model definitions. (You could also copy an instrument panel model definition and change the category to some other value if you want to. Regardless, to use an instrument panel, an entity’s model definition must include the instrumentPanelCategory parameter and set it to a valid value.)
If you create new instrument panels, you must add instrument panel model definitions for them and specify a value for the instrumentPanelCategory parameter. Then you can add the parameter to the appropriate entity model definitions.
VR-Forces can display the view from gimbaled visual sensors, such as a camera on a UAV. The view is displayed in an inset window that has information about the observer mode and area being viewed (Figure 51-6). The window has its own observer and you can change the observer mode in the view.
Each sensor view has a control panel (Figure 51-7) that you can use to move the sensor, change its aim, and zoom in and out.
Figure 51-7. Sensor Control Panel
The UAVSensorDemo example scenario demonstrates use of an entity with a gimbaled sensor. The scenario also has a Lua script that shows how to successively aim the sensor at many entities.
To display a sensor view:
Select an entity that has a gimbaled sensor.
Right-click the entity and on the right-click menu choose Create Sensor View
sensor, where sensor is one of the sensors on the entity.
You can display translucent cones that show the area on the terrain that a gimbaled sensor is observing. Each cone is a different color. Figure 51-8 shows two sensor field of view cones. One is focused on an entity and is zoomed in for a tight focus. The other is focused on a point on the terrain.
Figure 51-8. Sensor field of view cones
To display sensor field of view cones:
Choose Settings Display. The Display Settings dialog box opens.
In the list of settings, select the Sensor Fields of View check box.
You can also enable and disable sensor field of view cones by choosing Observer Sensor Fields of View or by clicking the Sensor Fields of View button 
) on the Observer Settings Toolbar.
When a sensor view opens, a control panel opens with it (Figure 51-7). This control panel works only with its associated sensor view. If you open multiple sensor views, there will be a control panel for each one. The Sensor Control Panel lets you do the following:
Aim the sensor at a simulation object or a point on the terrain. (You can also aim a sensor with the Sensor Aim set data request. For details, please see “Sensor Aim,” on page 34-38.)
Set the sensor to scan mode. (You can also set a sensor to scan with the Sensor Aim set data request.)
Take control of the sensor with a joystick. The joystick must be configured for use with the sensor view. For details about configuring joysticks, please see “Config- uring Joysticks and Keyboard Control,” on page 75-2.
Zoom the sensor. (You can also zoom a sensor with the Sensor Zoom set data request. For details, please see “Sensor Zoom,” on page 34-39.)
Move the sensor field of view. You can change the sensitivity of the movement buttons.
To aim the sensor at a simulation object:
Click the Aim at Simulation Object button 
). The Entity to Track dialog box opens.
Select the simulation object you want to aim at.
Click OK.
To aim the sensor view at a location:
Click the Aim at Location button 
). The Location to Track dialog box opens.
Click a location on the terrain or enter the coordinates in the dialog box.
Click OK.
To set a sensor to scan mode, click the Scan button ( ).
To control the sensor field of view with a joystick, click the Joystick button ( ).
To zoom the sensor view, adjust the Zoom slider.
To move the sensor view, click any of the arrow buttons.
To change the rate at which the arrow buttons move the sensor view, adjust the Rate slider.
Each simulation takes place within the extents of a terrain database. A terrain database provides three-dimensional information about a geographic area and provides the envi- ronment within which simulation objects function. With the information in a terrain database, VR-Forces calculates height, intervisibility, and other three-dimensional information.
VR-Forces allows you to load terrain data in the following basic ways:
Compose a terrain from elevation, imagery, and feature data.
Open an MTF or MTD1 file.
Stream terrain from local files or a terrain server such as VR-TheWorld Online.
Open a terrain database in a supported format, such as FLT, DTED, or GDB. The recommended work flow is:
Create an earth file.
Connect to the earth file.
Save the terrain as an MTF file.
Create a scenario and choose the MTF file as the scenario database.
The decision making process for choosing a terrain when you create a scenario is described in Chapter 7, Creating and Running Scenarios.
VR-Forces Users Guide
Section X - Terrain
X-1
Section X - Terrain
X-2 VT MAK
52. Introduction to Terrain Usage in VR-Forces
This chapter provides introductory information about terrain usage, including supported file formats, coordinate systems supported, and use of large terrain databases.
Composing Terrains (and Creating MTF Files) 52-2
Supported Feature Data Formats in the Front-end 52-4
Geometric Representation of Point Feature Data 52-5
Feature Data Types Supported by the Back-end 52-5
The UTM Coordinate System 52-6
Geocentric Terrain Databases 52-6
Loading Supported Databases 52-7
Using Large Terrain Databases 52-7
Introduction to Terrain Usage in VR-Forces — Composing Terrains (and Creating MTF Files)
VR-Forces lets you compose terrains from a variety of supported data formats. You can combine elevation data (terrain patches), imagery, and feature data to create terrains.
VR-Forces offers the following basic methods for creating terrains:
Compose a terrain by loading individual elevation, image, and feature data files. This method is best for relatively small terrains that do not require paging. It supports all of the coordinate systems that VR-Forces supports. For more informa- tion, please see “Creating a Composed Terrain,” on page 55-3.
Specify a set of files to load using an osgEarth format earth file. Use this method to stream terrain data from local or remote sources. This method is best for terrains with large amounts of elevation or image data, which would benefit from paging. For more information, please see “Connecting to Terrain Servers,” on page 56-2 and Chapter 57, Editing Earth Files.
When you compose a terrain, you can save it as a MAK terrain file (MTF), which is essentially a description of all of the data used to visualize the simulated 2D and 3D environment. Saving a terrain lets you automatically load all of the data that you loaded manually when you first created it.
You can save terrains in a cached format that loads terrain data more quickly than if the terrain is created from the source data. For details, please see “Configuring File Caching,” on page 61-2.
VR-Forces can import elevation, terrain, images, models, and feature data. Some types of files can contain more than one type of information. For example GeoTiff files can have elevation data or just have image data. The following sections list the supported formats.
Introduction to Terrain Usage in VR-Forces — Supported File Formats
VR-Forces imports terrain data directly as terrain patches. It supports the following formats:
MÄK terrain database (.gdb).
MÄK encrypted data format (.medf).
MÄK Stealth (6.2 and earlier) format (.mtl).
MÄK terrain project or terrain descriptor file (.mtp, .mtd).
OpenFlight (.flt).
MetaFlight (.mft).
CTDB 4, 7, 7L (.c4b, .c7b, .c7l).
Shape terrain data (.shp).
TerraPage (.txp).
3DS.
OBJ.
OSG.
LWO.
VR-Forces supports the following types of elevation data:
DTED (.dt0, .dt1, .dt2, .dted).
GeoTiff.
DEM.
Arc/Info Binary Data (.adf).
Other formats supported by osgEarth.
Introduction to Terrain Usage in VR-Forces — Feature Layers and Props
You can import images in the following formats:
GeoTiff (.tif, .tiff).
JPEG (.jpg, .jpeg).
PNG.
RGB.
Windows bitmap (.bmp).
GIF.
ECW.
Other formats supported by osgEarth using the GDAL driver. For a list of formats supported by GDAL, go to http://www.gdal.org/ and select the Supported Formats link. For more information about earth files, please see “Connecting to Terrain Servers,” on page 56-2 and Chapter 57, Editing Earth Files.
VR-Forces supports the following feature data formats in the front-end:
Shape files.
S-57.
OGR vector formats referenced in earth files.
For more information, please see “Adding Props to a Terrain,” on page 55-19.
Introduction to Terrain Usage in VR-Forces — Feature Layers and Props
There are differences between how the front-end and back-end process feature data. This is because the information needed to simulate simulation object interaction with features is different from the information needed to render the scene.
The front-end renders point features such as building or trees based on the data provided in the feature layer. As mentioned in the previous section, you can extract these objects as props, in which case they are represented as geometric objects in the terrain.
If you are streaming features using an earth file, you can configure the earth file to extrude buildings into 3D geometry. This capability is demonstrated in some of the insets in MAK Earth (online).mtf, for example the Boston and Honolulu insets.
The back-end representation of point features depends on how they are used. Collision avoidance treats them as bounding volumes with infinite height. Line-of-sight calcula- tions treat them as bounding volumes with a defined height. If you extract features as props, the back-end treats them as geometry where that is appropriate and as features otherwise.
The back-end does not recognize extruded geometry.
The back-end supports the following types of feature data files:
MÄK terrain database (.gdb).
CTDB 4, 7, 7L (.c4b, .c7b, .c7l).
Shape terrain data (.shp).
S-57.
WFS.
OGR vector formats referenced in earth files.
VMAP.
The preferred format for adding features is shapefiles. You can extract feature data from GDB, DFD, VMAP, and CTDB into shapefiles with the vectorNetworkToShapeFiles utility. For details, please see Section 62.7, “Extracting Feature Data from GDB to Shapefiles”. You can extract feature data from S-57 files into shapefiles with the ogr2ogr tool. For details, please see Section 62.8, “Converting S-57 Feature Data to Shapefiles”.
Introduction to Terrain Usage in VR-Forces — Coordinate Systems
There are several types of UTM systems. In general, the earth is divided into 60 zones generally 6 degrees wide in longitude. These zones may be further subdivided into quadrangles by using letter designations from south to north. This complicates refer- ences to UTM. For example, standard offset could be used with or without the quad- rangles (which affects the northing portion of the coordinate), non-offset does not use the quadrangles, and Milgrid requires the quadrangles.
More specifically, UTM coordinates define two dimensional, horizontal, positions. UTM zone numbers designate 6 degree longitudinal strips extending from 80 degrees South latitude to 84 degrees North latitude. UTM zone characters designate eight degree zones extending north and south from the equator. There are special UTM zones between 0 degrees and 36 degrees longitude above 72 degrees latitude and a special zone 32 between 56 degrees and 64 degrees north latitude.
VR-Forces uses the following definition:
A non-Cartesian coordinate system in which the X, Y, and Z correspond to easting (nearly east), northing (nearly north), and height above an ellipsoid that approximates the surface of the earth. When in UTM mode (the default), VR-Forces uses an offset UTM coordinate system, one in which coordinates are expressed with respect to an origin located at the latitude and longitude specified in a configuration file. Typically, this will be the location of the origin of your terrain database.
To support large play areas, simulations can use geocentric coordinates. In the geocen- tric coordinate system, the origin is at the center of the earth. The positive X-axis passes through the prime meridian at the equator; the positive Y-axis passes through 90 degrees east longitude at the equator; and the positive Z-axis passes though the North Pole.
MTF files reference elevation, image, and feature files that VR-Forces processes and loads when you load a scenario. However, you can also load terrain databases directly into VR-Forces. They will be converted to the VR-Forces internal format using default values. This process is less efficient than loading MTF terrains, may take more time, and must be repeated each time you load the terrain as part of a scenario or in the front- end.
When you create a scenario you can choose a terrain in any supported format. If you want to open a terrain using the File Open Terrain menu option, you can only choose MTF files. To load non-MTF terrains out of the context of creating a scenario, you must load it as a terrain patch.
If you load a terrain directly, you can still save it to MTF.
VR-Forces can support large databases, where large might mean a high polygon count, a large geographic area, or both. VR-Forces supports two methods for dealing with large databases – terrain paging and streaming terrain. Both approaches have a common goal – providing access to large amounts of data without loading all of that data into memory at any one time.
VR-Forces cannot arbitrarily page or stream terrains. It can page terrains that have been designed for paging and can stream terrains that are accessed through a terrain server, such as VR-TheWorld Server. For details about support for paged terrains, please see “Loading MetaFlight Terrains,” on page 56-5. For details about connecting to terrain servers, please see “Connecting to Terrain Servers,” on page 56-2 and “Creating a Terrain with an Earth File,” on page 63-14.
Even if you use terrain paging or streaming terrain, it is still possible that a large terrain could exceed the memory limitations of your operating system.
In general, the simulation engine does not load terrain until it needs the terrain to support the objects in the scenario. (Some terrain data is always loaded immediately, such as terrain data in OpenFlight format.) For example, if you create a new scenario and specify a paged terrain, the simulation engine does not load terrain until you create a simulation object. Then it only loads the terrain page required for the object.
When you run a scenario, as simulation objects move, the simulation engine tries to predict which terrain pages it will need to support the simulation objects and tries to page them in before the simulation objects need them. If the total polygon count required to page in required terrain exceeds the maximum polygon count configured, VR-Forces pages out (removes) unused pages. The simulation engine pages out the least recently used data.
Predictive terrain paging is done in real time, not just when a scenario is running. For example, when you load a scenario, all required terrain is paged in and when you add objects during scenario creation, terrain is paged in.
You can also manually page in terrain using terrain page-in areas. For details, please see “Manually Paging-In Terrain,” on page 56-6.
Paging is done based on the following priorities:
If a simulation object is moving, paging in terrain that it needs is a higher priority than predictive paging.
Blocking terrain calls have a higher priority than non-blocking calls. (A blocking call is one that prevents the simulation from progressing until the call is completed. For more information, please see the assertOnBlockingTerrainCalls parameter in Table B-1, in “The vrfSim.mtl Configuration File,” on page B-2.)
Paging out terrain to recover memory is a higher priority than paging in terrain. The need to page out is calculated based on the polygon count of the terrain, not on its memory usage.
VR-Forces can display information about paged terrains that can help you understand how your terrain is performing and why objects may be interacting with it as they do. For details, please see “Displaying Information About Paged and Streaming Terrains,” on page 56-7.
The term terrain paging is used in reference to static, local terrains. Another way to load terrain data for a large area is to stream it from a terrain server. The idea is similar to terrain paging. Only the data you need at a particular location is loaded. The difference is that a terrain server can serve many computers at a time and normally holds much more data than a static local terrain. It can stream elevation data, imagery, map data, and feature data. It may have data at multiple levels of resolution for a particular portion of the terrain. VR-Forces supports connection configurations to terrain servers, including MAK’s VR-TheWorld Server.
53. Displaying Terrain Infor- mation
This chapter describes how to change the display of terrain to provide different types of useful terrain information.
Configuring Visible Surfaces (GDB Soil Types) 53-2
Coloring Terrain Based on Elevation 53-4
Configuring Elevation Color Settings 53-5
Configuring Contour Lines 53-10
Displaying Models and Terrain in Wireframe Mode 53-10
Filtering Earth File Layers 53-12
Displaying Feature Data (2D) 53-13
Displaying a List of Vector Features 53-14
Changing the Colors Used for Feature Data 53-15
Displaying Coordinates and Soil Type for a Location 53-16
Using Terrain Draw Areas to View Terrain Polygons 53-18
Terrain Databases Provided with VR-Forces 53-19
Displaying Terrain Information — Introduction
As you create and view simulations, you may need information about the terrain. By changing how terrain is displayed, you can get some of this information. If your terrain does not have texture data or an image overlay, features such as elevation coloring can provide a more realistic look to the terrain.
For information about how to compose terrains, please see Chapter 55, Composing Terrains.
If a terrain patch was loaded from a GDB file, you can display or hide GDB soil types. Figure 53-1 shows the makland.gdb terrain file. The view on the left shows all soil types. The view on the right has Building, Grass, Ocean, and Rock surfaces hidden.
Figure 53-1. Visible surfaces toggled off
Displaying Terrain Information — Configuring Visible Surfaces (GDB Soil Types)
To display or hide GDB soil types:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Visible Surfaces page (Figure 53-2).
In the Terrain Patches list, select the terrain patch that you want to configure.
Select the check box for each soil type that you want to be visible.
Clear the check box for each soil type that you want to hide.
To change the state of multiple soil types at one time:
Select (highlight) the names (not the check boxes) of the soil types whose state you want to change.
Click Toggle Selected Surfaces.
You can color the terrain based on elevation.
To enable or disable coloring of terrain by elevation:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Elevation Color page (Figure 53-3).
In the Terrain Patches list, select the terrain patch for which you want to enable elevation coloring.
Select or clear the Enable Elevation Coloring check box.
Displaying Terrain Information — Coloring Terrain Based on Elevation
You can specify the color applied to terrain at a given altitude. You can add altitude points and remove them.
To insert an altitude point:
Choose Settings Terrain. The Terrain Settings dialog box opens.
In the Terrain Patches list, select the terrain patch for which you want to insert an altitude point.
Select an altitude point in the list that is above or below the altitude point you want to add.
Click Insert Point. A new point is added with the same altitude as the one you selected.
Double-click the new altitude point to make it editable.
Set the altitude point to the altitude that you want.
Click away from the altitude point to set it.
To delete an altitude point:
Choose Settings Terrain. The Terrain Settings dialog box opens.
In the Terrain Patches list, select the terrain patch for which you want to delete an altitude point.
Select the altitude point that you want to delete.
Click Delete Point.
To change the color of an altitude point:
Choose Settings Terrain. The Terrain Settings dialog box opens.
In the Terrain Patches list, select the terrain patch for which you want to change the color of an altitude point.
Double-click the color swatch for the altitude point whose color you want to change. A color chooser dialog box opens.
Select or specify a new color.
Click OK.
Displaying Terrain Information — Displaying Grid Lines
VR-Forces can display grid lines in the 2D view. Grid-lines are an observer-specific setting.
To enable or disable grid lines:
Choose Settings Display. The Display Settings dialog box opens.
Select the Observer Settings page (Figure 53-4).
Select Plan View mode (or a locally created 2D observer mode).
Select or clear the Grid Lines check box.
i You can also enable or disable grid lines by choosing Observer Grid Lines.
Displaying Terrain Information — Displaying Grid Lines
You can configure the coordinate system used for grid lines, the precision, and the spacing. Spacing can be fixed, in meters, or determined by VR-Forces using a specified number of screen pixels. Fixed spacing can result in a very tight grid and unreadable labels as you zoom out. Auto spacing does not have this problem. However, the grid lines will constantly recalculate as you zoom in and out.
To configure grid lines:
Choose Settings Display. The Display Settings dialog box opens.
Select the Grid Lines Settings page (Figure 53-5).
To change the coordinate system used for grid lines, select an option in the Grid Line Type list. The list displays grid line types that are appropriate for the type of database loaded. (If no database is loaded, the coordinate system is set to Flat Earth.)
To specify the unit type for the grid line labels, select an option on the Unit Type list.
To specify the precision of the grid line labels, type a value in the Decimal Places box.
To change the spacing type, select AutoSpacing or Fixed Spacing and specify a value for the chosen spacing type.
To specify an offset from the origin, change the values for X Offset and Y Offset.
Displaying Terrain Information — Displaying Contour Lines
You can display contour lines and intermediate contour lines on the terrain. Interme- diate contour lines divide the contour line interval into fifths (Figure 53-6). You can configure the thickness of contour lines and the interval between them.
Figure 53-6. Contour lines and intermediate contour lines
To display contour lines:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Contour Lines page (Figure 53-7).
Figure 53-7. Contour Lines page
Displaying Terrain Information — Displaying Models and Terrain in Wireframe Mode
In the Terrain Patches list, select the terrain patch for which you want to enable or disable the display of contour lines.
Select Enable Contour Lines.
To enable intermediate contour lines, select Enable Intermediate Contour Lines.
You can configure the thickness of contour lines and the interval between them.
To configure contour lines:
Choose Settings Terrain. The Terrain Settings dialog box opens.
In the Terrain Patches list, select the terrain patch for which you want to configure the thickness and interval of contour lines.
In the Contour Line Interval text box, specify the distance, in meters, between contour lines.
In the Contour Line Thickness text box, specify the thickness, in pixels, for contour lines.
In wireframe mode, VR-Forces displays the polygons that make up the terrain and objects (Figure 53-8).
Figure 53-8. Wireframe off and on
Displaying Terrain Information — Displaying Models and Terrain in Wireframe Mode
To enable or disable wireframe mode:
Choose Settings Display. The Display Settings dialog box opens.
Select the Render Settings page (Figure 53-9).
Select the Enable Wireframe Rendering Mode check box.
You can also enable and disable wireframe mode by choosing Settings
Wireframe Rendering.
Displaying Terrain Information — Filtering Earth File Layers
When you load a terrain using an earth file, imagery and feature data is specified in image elements and model elements. You can load multiple instances of these types of data, resulting in a rich, complex terrain. However, if you are only interested in certain types of terrain features, such as roads or rivers, displaying all of the terrain data can obscure the data that you are most interested in. To help declutter the map, you can filter out image and model layers globally or by observer mode.
This feature is particularly useful if you want to show some layers in the PVD observer mode and others in one of the 3D observer modes. Settings are saved to the MTF file so that they are in effect in all scenarios that use the terrain.
Filtering an earth file layer affects all open windows. You cannot hide a layer in one window and leave it open in a different one.
Filtering only affects the front-end. All layers are loaded in the back-end.
To filter out earth file layers:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Earth Layers page (Figure 53-10).
All observers
Specific observers
To display or hide an image or model layer for all observer modes, select or clear its check box.
To display or hide an image or model layer for a particular observer mode, expand the entry for the layer you want to change and select or clear the check box for the observer mode you want to change.
If a terrain contains feature data, you can display it in the 2D view. Figure 53-11 shows a section of the Little Pond terrain with features disabled and enabled.
This setting only displays features imported from GDB files or shapefiles. It does not display features streamed from a terrain server. If you load features using an earth file, they are drawn (or not drawn) based on the configuration information in the file.
i If your terrain has many features, displaying them can take a long time.
To display feature data, choose Observer Features.
Displaying Terrain Information — Displaying Feature Data (2D)
Figure 53-12. Vector feature selected
To display the feature list:
Choose View Terrain Information Panel. The Terrain Information Panel opens.
Expand the top-level categories to see the lists of individual features.
If a terrain database contains feature data, you can change the colors used to display it. In Figure 53-13, the Woodland feature in the Little Pond terrain was changed to pink. Compare it to the default color (Figure 53-11).
Figure 53-13. Feature data with color change
To change the color of feature data:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Feature Settings page (Figure 53-14).
Click the color swatch for the feature that you want to change. A color picker dialog box opens.
Displaying Terrain Information — Displaying Coordinates and Soil Type for a Location
Select the color that you want to use.
Click OK.
The Last Clicked Location Panel becomes unavailable if you query the simulation engine and it takes more than 1/2 second for a response.
To check the coordinates and soil type of a feature or location:
If the Last Clicked Location Panel is not open, choose View Last Clicked Loca- tion.
Figure 53-15. Last Clicked Location Panel
If you want soil type information, select Query Sim Engine.
Click a point on the terrain or click a feature. Information is displayed in the Last Clicked Location Panel.
Displaying Terrain Information — Viewing the Map Scale
If you want to know the relationship between distance on your computer screen and distance on the terrain, you can view the Map Scale Toolbar (Figure 53-16). It shows the scale between screen space and world space, that is, one inch of screen = x inches of ground distance, or one meter of screen = x meters of ground. The scale changes as you zoom in and out.
Figure 53-16. Map Scale Toolbar
To enable or disable display of the Map Scale Toolbar, choose View Map Scale Toolbar.
Displaying Terrain Information — Using Terrain Draw Areas to View Terrain Polygons
Terrain draw areas display the polygons known to the simulation engine (Figure 53-17). They can be useful if you are debugging terrain issues. To view polygons, you must select the terrain draw area and the scenario must be running.
Figure 53-17. Terrain draw area
To view terrain polygons using a terrain draw area:
On the Tactical Graphics Palette, select Terrain Draw Area.
Draw an area. For details about drawing tactical graphics, please see Chapter 16,
Creating and Placing Objects.
Select the area.
Run the scenario.
Displaying Terrain Information — Terrain Databases Provided with VR-Forces
Table 53-1 describes the terrain databases provided with VR-Forces. Some have vari- ants, which indicate the coordinate system or other variations. Terrains with “(online)” in the title connect to VR-TheWorld Server or another online server and require an internet connection. Some terrains have variations that emphasize a particular set of features or other data. VR-Forces also has a supplemental data package that includes additional terrains. Please contact your MAK salesperson for download details.
Table 53-1: Terrain databases shipped with VR-Forces (Sheet 1 of 2)
Variation Description
Variation Description
Ala Moana.mtf A high-resolution area of Honolulu, Hawaii, USA, set into a raster map of the world. This terrain is stored locally and does not require an internet connection.
Bakersfield Topo Map (online).mtf
Brooklyn.mtf Brooklyn (online).mtf
VR-TheWorldOnline with topographical maps for the area around Bakersfield, California, USA. This terrain contains some feature data that simulation objects in aggregate-level scenarios can take advantage of.
A high resolution city center surrounded by an extruded cityscape. Located geographically in Brooklyn, N.Y., USA, but not an actual location in that city.
Ground-db.mtf UTM. OpenFlight. A generic relatively flat ground terrain.
LittlePond.mtf LittlePond (online).mtf
MAK Earth - Base (online).mtf The base VR-TheWorld Server terrain with a high
resolution inset for Honolulu, Hawaii, USA and the surrounding area. Does not include streaming feature data. Includes streaming feature data.
MAK Earth (online).mtf VR-TheWorld Server terrain with a high resolu-
tion inset for Honolulu, Hawaii, USA and other cities. Includes streaming feature data.
Makland.mtf UTM. OpenFlight. A fictional terrain created by MÄK. It includes a variety of terrain and feature data, including underwater features. It is placed in the Indian Ocean.
Massachusetts S-57 (online).mtf VR-TheWorld Server with S-57 data (as shape-
files) for Boston harbor.
NorthAfrica (online).mtf
Displaying Terrain Information — Terrain Databases Provided with VR-Forces
Table 53-1: Terrain databases shipped with VR-Forces (Sheet 2 of 2)
Variation Description
Variation Description
ProceduralEarth (online).mtf
ProceduralEarth - Open- StreetMap (online).mtf
ProceduralEarth - No Airports (online).mtf
ProceduralEarth - Experimental (online).mtf
Procedurally generated terrains. Images are generated based on land use data, resulting in high quality visual imagery without the overhead of high resolution static images. Terrains may include airport data for all airports in the world, street data from OpenStreetMap.
RhoneValley (online).mtf A procedurally generated view of the Rhone
Valley in France.
SanLuisObispo.mtf Flat earth. DTED. Imagery. A terrain that covers
a portion of California, U.S.A.
SanLuisObispoTopoGdal.mtf Geocentric. San Luis Obispo in topographic coor-
dinates as local streaming terrain using an earth file.
Test-CDB-SanLuisObispo.mtf An example of loading CDB terrain data using an
earth file.
Test-DestructibleTerrain.mtf A small test terrain that has buildings and a
bridge that can be destroyed and windows and doors that can open and close based on changes to switch nodes.
VR-Village.mtf GDB. Feature data. OpenFlight terrain. VR- Village is a fictional database created by VT MAK. It has a highly detailed small town in a larger, sparsely detailed desert environment. The town includes multi-level buildings, underground tunnels, and a road that tunnels through a moun- tain. The coordinates place it off the west coast of Africa.
VR-Village Afghanistan (online).mtf
Geocentric. The high resolution data from VR- Village.mtf is inset in Afghanistan in VR- TheWorld online server.
WorldFlatEarthNoElevation.mtf Flat earth. Low resolution projected image of the
world.
WorldGeocentric.mtf Geocentric. Low resolution projection of the world.
WorldGlobalWater.mtf A terrain with no elevation data for land masses.
This chapter explains what terrain profiles are and how to display and configure them. Terrain Profiles 54-2
Displaying a Line’s Terrain Profile 54-3
Configuring Terrain Profiles 54-3
Analyzing Terrain Using a Terrain Profile Line 54-6
You can display terrain profile windows for line objects that have height (in other words, routes and lines, but not phase lines), for intervisibility lines, and for a simula- tion object’s track history. You can also create lines specifically for the purpose of showing the terrain profile. A terrain profile displays:
A graph of the line against the terrain.
Simulation objects within a specified distance of the line or track.
Location of any one point along the line.
The location on the grid of the cursor. This helps you estimate distances between the grid lines.
In Figure 54-1, the yellow line (1) represents the terrain and the red line (2) shows a route. The location of the cursor in grid coordinates is displayed (3) and the location of one point along the terrain is displayed (4). Several entities are close to the route and they are shown as well (5).
1 2 3
4
5
You can display a terrain profile for routes, intervisibility lines, and terrain profile lines.
To view a line’s terrain profile, use one of the following methods:
Right-click a line and choose Terrain Profile from the popup menu.
Open the Edit dialog box for a line and click Terrain Profile. (You can configure terrain profiles to open automatically when you open an Edit dialog box.)
To display the terrain profile for a track history, follow the procedure in “Displaying a Terrain Profile for a Track History,” on page 42-7.
You can configure the following aspects of a terrain profile:
The frequency, in distance, at which terrain height is sampled to create the graph in the Terrain Profile window.
The maximum number of points to sample along a line.
Whether or not terrain profiles should be displayed automatically when a line is created or edited.
To configure terrain profiles:
Choose Settings Display. The Display Settings dialog box opens.
Select the Terrain Profile Settings page (Figure 54-2).
Change settings as desired. Table 54-1 describes the configuration options:
Table 54-1: Terrain profile parameters
Option Description
Option Description
Show Objects Near Line If enabled, displays icons for simulation objects
near the line. The text box specifies the distance from the line within which simulation objects are displayed.
Terrain Sample Rate Specifies the frequency at which the terrain is
sampled along the line.
Maximum Sample Points Specifies the maximum number of sample points
for a line.
Show Vertices On Line If enabled, the vertices of the line are displayed.
Table 54-1: Terrain profile parameters
Option Description
Option Description
Show Profile During Creation If enabled, a terrain profile window opens while
intervisibility lines, routes, or both are created.
Show Terrain Profile When Editing Routes
If enabled, a terrain profile window opens when you edit a route.
Using Terrain Profiles — Analyzing Terrain Using a Terrain Profile Line
A terrain profile line is a special line used to analyze the terrain. It is more versatile than a point-to-point intervisibility line because it can have multiple points, which allows a finer analysis of the terrain. Unlike a route (for which you can also view terrain profiles), a terrain profile line is not published, so it has less overhead and does not clutter up object lists.
To create a terrain profile line:
Choose Intervisibility Create Terrain Profile Line. A Terrain Profile window opens and the cursor changes to draw mode.
Click on the terrain to place the vertices of the line. As you add vertices, the Terrain Profile window updates to show the profile of the line (Figure 54-3).
Right click to finish the line.
After you create a terrain profile line, you can edit it just like any other line. For details, please see “Editing Vertices,” on page 39-13.
This chapter explains how to combine various types of data to build a terrain. For basic conceptual information about terrain agility, please see Section X, “Terrain,”. “Composing a Terrain through the GUI,” on page 63-2 is a tutorial that steps you through the entire process of creating a terrain. For information about paged and streaming terrains, please see Chapter 56, Paged and Streaming Terrains.
Creating a Composed Terrain 55-3
Considerations and Limitations for Building Terrains 55-4
Adding Elevation Data (Terrain Patches) to a Terrain 55-5
Adding Images to a Terrain 55-7
Changing the Display Order of Raster Maps 55-10
Adding a Dynamic Ocean Layer 55-13
Extracting Water Textures and Adding an Ocean Layer 55-15
Adding a Dynamic Ocean Layer Directly 55-16
Setting the Ocean LOD Elevation 55-16
Configuring the Ocean Height Map 55-17
Adding Props to a Terrain 55-19
Extracting Props from a Terrain Patch 55-20
Adding Props from a Feature Layer 55-22
Setting the Opacity of Props 55-25
Changing a Prop’s Position or Orientation 55-26
Changing a Prop’s Model Definition 55-26
Composing Terrains
Specifying Simulation Ocean Settings 55-27
Composing Terrains — Creating a Composed Terrain
The most common ways to compose a terrain in VR-Forces are as follows:
Load individual terrain components through the VR-Forces GUI and then save the terrain as an MTF file.
Create an earth file that specifies all the terrain components to load. Then load the earth file and save it as an MTF file.
Load an earth file and add local terrain components. Then save the terrain as an MTF file.
This section describes the first option, creating a terrain by loading individual elevation, imagery, and feature files. (Using earth files is the preferred method. For details about using earth files, please see Chapter 56, Paged and Streaming Terrains and Chapter 57, Editing Earth Files.) The general procedure for composing a terrain this way is as follows:
Choose File New Terrain, or click the New Terrain button ( ) on the Terrain Toolbar. If any terrain data is loaded, it is removed.
Add elevation data, as described in “Adding Elevation Data (Terrain Patches) to a Terrain,” on page 55-5.
Optionally, add imagery, as described in “Adding Images to a Terrain,” on page 55-7.
Optionally, add feature data, as described in “Adding a Feature Layer,” on page 55-11.
Optionally, add a dynamic ocean layer, as described in “Adding a Dynamic Ocean Layer,” on page 55-13.
Optionally, add props or extract props, as described in “Adding Props from a Feature Layer,” on page 55-22 and “Extracting Props from a Terrain Patch,” on page 55-20.
Save the terrain, as described in “Saving a Terrain,” on page 55-4.
“Composing a Terrain through the GUI,” on page 63-2, demonstrates how to create a composed terrain.
For a list of supported terrain and feature formats, please see “Supported File Formats,” on page 52-2.
Composing Terrains — Creating a Composed Terrain
As you compose a terrain, consider the following issues:
VR-Forces supports DTED level 0, 1, and 2. DTED is loaded using a Flat Earth projection. The default post spacing for DTED level 0 is 1. For other levels it is 5. You can load a 1 degree cell.
If you load more than one DTED cell, they will be placed on top of each other. If you need to load multiple DTED cells, you can do so using an earth file. For details, please see “Loading Multiple DTED Files,” on page 57-6.
The larger a terrain database is (as measured by the number of polygons), the more it will affect performance.
By default, when you load DTED files as terrain patches, the files are loaded with their altitude referenced to WGS84. If you want the altitude to reference a different vertical datum (most likely EGM96), you must provide a geoid grid file for that vertical datum. If you use a geoid grid file, the altitudes in the DTED file are adjusted based on the information in the grid file.
To use a geoid grid file, set the environment variable MAK_GEOID_GRID to the path of the file.
i This section does not apply to terrains loaded using an earth file.
When you save a terrain, VR-Forces saves information about the terrain patches, imagery, and feature layers that you used to create the terrain. Saving a terrain does not save out data to a file format comparable to OpenFlight or GDB that can be loaded into other applications or converted into other formats. If accelerated file loading is enabled, the data gets saved in a format that can be loaded more quickly than from its native format. (For details about accelerated file loading, please see “Configuring File Caching,” on page 61-2.) Terrains get saved with the extension .mtf.
When you save a terrain to MTF, if an MTD file of the same name exists, a dialog box explains your options for saving the file. (MTD is a legacy format that might be present if you have terrains created with older versions of VR- Forces.)
Composing Terrains — Adding Elevation Data (Terrain Patches) to a Terrain
To save a terrain:
Choose File Save Terrain, or click the Save Terrain button ( ) on the Terrain Toolbar. The Save Terrain dialog box opens.
Type a name for the terrain.
Click Save.
To build a terrain database, you load elevation data, imagery, and feature data. Then you save the data collection in MTF format. Elevation data is added as terrain patches. Note the limitations in “Considerations and Limitations for Building Terrains,” on page 55-4.
!
!
Each time you add a terrain patch, VR-Forces resets the origin and coordinate system. Therefore, if you add multiple terrain patches, any patches whose origin and coordinate system do not match the patch that is loaded last will not be usable.
Composing Terrains — Adding Elevation Data (Terrain Patches) to a Terrain
To add a terrain patch to a terrain database:
Choose Settings Terrain, or click the Add Terrain Patch button ( ) on the Terrain Toolbar. The Terrain Settings dialog box opens.
Select the Terrain Contents page (Figure 55-1).
Click Add Terrain Patch. The Add Terrain Patch dialog box opens and an Open dialog box opens on top of it.
Select a file in a supported format.
Click Open. The Add Terrain Patch dialog box displays details about the terrain patch (Figure 55-2).
If the terrain patch has DDS textures that are upside down relative to VR-Forces’s expectations, select Flip DDS Textures. This setting does not affect paged terrains. (For information about DDS textures, please see “Displaying DDS Textures Correctly,” on page 61-10.)
Click OK. The terrain patch is added.
Optionally, add additional terrain patches.
Save the terrain.
Depending on your terrain source, you may have terrain polygonal data, but no texture data or feature data to provide a realistic 3D display. You can drape images (raster maps) over the terrain to provide a more pleasing display.
Adding very large images (multi-100 GB) may cause VR-Forces to crash. If you need to load very large images, load them using an earth file and the GDAL driver. The SanLuisObispo-Imagery.earth file demonstrates how to load an image using this method. You can also use the GDAL driver to load raster formats that VR-Forces cannot load directly. For a list of formats supported by GDAL, go to http://www.gdal.org/ and select the Supported Formats link.
To add raster maps to the terrain:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Raster Maps page.
Click the Add button ( ) that is above the list of raster maps. A line is added to the Raster Maps list (Figure 55-3).
Change Order Add Remove
Click the Browse button to the right of the new line. The Image File dialog box opens.
Select the raster image that you want to add to the terrain.
Click OK. The image is listed in the Raster Maps window. To view it in the main window, select the check box to the left of the entry (Figure 55-4).
Optionally, specify the attributes of the image, as follows:
Blend specifies how the image interacts with underlying images, as follows:
Decal: covers the polygons with the image. Use it to apply an opaque texture or a texture with transparency. (This is done using an alpha channel.)
Modulate: color values of the image modify the intensity of the colors of the polygon.
Blend: blends polygon and texture colors.
Replace: similar to decal.
Wrap specifies whether or not the image is repeated, and if so, how it is repeated, as follows, and as illustrated in Figure 55-5 and Figure 55-6:
Clamp: extends the border pixels of the image to the edge of the terrain or the next continuous image, blending them with the pixels of other images. It does not obscure underlying images.
Clamp to Edge: extends the border pixels over the entire terrain, obscuring any other image.
Clamp to Border: places the image once, at the specified coordinates.
Repeat: tiles the image onto the terrain.
Mirror: tiles the image onto the terrain, alternating between the true image and a mirror image.
Coordinate System specifies the coordinate system to use to place the image.
Most options are self-explanatory. The Texture coordinate system specifies UV (X,Y) coordinates for placing textures on the terrain.
Clamp Clamp to border
Figure 55-5. Raster image wrap effects (Clamp and Clamp to Border)
Clamp to edge
Repeat
Mirror
Figure 55-6. Raster image wrap effects (Clamp to Edge, Mirror, Repeat)
Raster maps are displayed in the order in which they are listed in the Terrain Settings dialog box, Raster Maps page. If they overlay the same portion of the terrain, the topmost image is displayed. You can change the order in which image files are listed, thereby changing which one is displayed in VR-Forces.
Figure 55-7 shows two views of the detailed portion of the LittlePond terrain, one with the default image order, and one with the order of raster images reversed.
Figure 55-7. Changing the raster map order
To change the order of a raster map.
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the raster image whose order you want to change.
Click the Up Arrow or Down Arrow above the upper right corner of the list of raster maps. The image moves in the list and the window changes as appropriate.
Composing Terrains — Adding a Feature Layer
The front-end and back-end use different mechanisms to import feature data and they handle it differently.
./appData/importConfig/filename_shp_map.txt. For example, the file name ROADL.shp
is mapped to feature 129, which is a road. If the shapefiles that you need to import are not listed in filename_shp_map.txt, you can add them by editing the file.
!
!
Loading large feature layers into the front-end can cause it to hang and scenario data can be lost. To avoid this problem, you can choose to load feature layers only in the simulation engine. In this case, you will not be able to visualize the feature data, but the simulation engine will handle it correctly.
When the back-end imports feature data, it configures it based on a configuration file called ./appdata/settings/featureconfig.txt. For details about this file, please see Chapter 62, Configuring Feature Data.
The preferred method for adding feature data in the back-end is via shapefiles. Loading shapefiles in the back-end, as compared to loading feature data from a GDB file, provides better performance. If you have feature data in GDB files and you need to import it into VR-Forces, you can extract it from the GDB to a shapefile using the vectorNetworkToShapeFiles utility. For details, please see “Extracting Feature Data from GDB to Shapefiles,” on page 62-7.
Composing Terrains — Adding a Feature Layer
Adding a feature layer does not, by itself, make any visible difference to a terrain. To see the feature data, you must extract the data as props and map the props to model definitions. For details, please see “Adding Props to a Terrain,” on page 55-19.
The number of layers you can add depends on your graphics card. If you add a layer and it does not appear, try reducing the number of layers you have.
Feature layers in earth files are added automatically.
VR-Forces supports S-57 data. The recommended way to load S-57 data is to convert it to shapefiles and load the shapefiles. You could load them as feature layers as described in this section. However, since each S-57 file is converted to multiple shapefiles, it may be easier to load them using earth files than as individual shapefiles. VR-Forces includes one terrain that has S-57 data, Massachusetts S-57 (online).mtf.
To add a feature layer:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Terrain Contents page (Figure 55-8).
Click Add Feature Layer to load a feature layer in the front-end and back-end. Click Add Simulation Feature Layer to add a feature layer only in the back-end. The Select Source File for Feature Layer dialog box opens.
In the Select Source File for Feature Layer dialog box, select the file that you want to use for this feature layer.
Click Open. The source file is added to the list of terrain contents. The Status column indicates whether the feature layer is for visualization and simulation (Visualized) or just simulation (Not Visualized)(Figure 55-9).
Figure 55-9. Terrain contents status
If your terrain has textures assigned to water polygons, then you should extract them. They will be replaced by the ocean layer. If you do not extract the water textures and you simply add an ocean layer, the ocean layer and the water texture will interfere with each other in a process called Z-fighting and create an unacceptable display (Figure
55-10). This problem occurs because the ocean layer and the texture are both at the same height (0, or sea level).
If your terrain does not have a specific water texture assigned to polygons, your only option is to add an ocean layer directly. However, since the ocean layer will be at the same elevation as the terrain texture, you may experience Z-fighting. You may also have to raise the ocean height to actually see the ocean effects.
Figure 55-11 shows the Makland terrain with a water texture and an ocean layer. In the left view, the ocean layer has a height of 0 meters. You cannot see it. In the right view, the ocean layer is set to 1 meter. Now it is visible.
To extract textures and add an ocean layer:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Extract Ocean page (Figure 55-12).
Figure 55-12. Terrain Settings dialog box, Extract Ocean page
In the External References list on the Extract References tab, select the water textures that you want to extract.
Click Extract Selected. The textures are removed and an ocean layer is added to the Terrain Contents page.
Select the Terrain Contents page (Figure 55-13).
Adjust the Ocean Height so that the dynamic ocean is visible. This might require raising the ocean above sea level.
Optionally, adjust the Ocean LOD Elevation. For information about the Ocean LOD Elevation, please see “Setting the Ocean LOD Elevation,” on page 55-16.
Ocean layers get created at a height of 0 meters, that is, mean sea level.
To add a dynamic ocean layer:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Terrain Contents page.
Click Add Dynamic Ocean Layer. (You can only have one ocean layer.) A layer is added to the Terrain Contents list and two parameters are added to the bottom of the dialog box (Figure 55-13).
Adjust the Ocean Height so that the dynamic ocean is visible. This might require raising the ocean above sea level.
Optionally, adjust the Ocean LOD Elevation. For information about the Ocean LOD Elevation, please see “Setting the Ocean LOD Elevation,” on page 55-16.
To set the ocean LOD elevation:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Terrain Contents page (Figure 55-13).
Adjust the Ocean LOD Elevation slider or change the value in the box.
Height map resolution is specified as meters per pixel. The height map texture size is specified in pixels. Therefore these two settings determine the length of one side of the (square) area that the height map covers. For example, if the value for height map reso- lution is 10 meters per pixel and the texture size is 4096 pixels, this results in a height map that is 40960 meters on a side.
If you are working with a small terrain or scenes in which the observer is close to sea level, you may want to use a higher resolution. If you are less interested in how the coastline looks, you can use a lower resolution. Figure 55-13 shows a coastline at different levels of resolution.
1.0 15.0
Figure 55-14. Ocean height map resolution
Setting the surface transparency also affects visualization of the coastline. Experiment with these values to achieve the best results. For details about water transparency, please see “Configuring Marine Conditions,” on page 11-17.
The ocean height map resolution is specified at meters per pixel.
To set the ocean height map resolution:
Choose Settings Display. The Display Settings dialog box opens.
Select the Ocean Settings page (Figure 55-15).
Adjust the Ocean Height Map Resolution slider, or enter a value in the box.
The ocean height map texture size is specified in pixels.
To set the ocean height map texture size:
Choose Settings Display. The Display Settings dialog box opens.
Adjust the Ocean Height Map Texture Size slider, or enter a value in the box.
The ocean height map is recalculated as the observer moves. Generating the height map is computationally expensive. Therefore, it is done only when the observer moves by more than a specified threshold. You can adjust this threshold if you want to recalculate the height map more frequently. The default is 10% (0.1). This means that the observer must move by 10% of the length of one side of the height map before the height map is regenerated.
To set the ocean height map regeneration threshold:
Choose Settings Display. The Display Settings dialog box opens.
Adjust the Ocean Height Map Regeneration Threshold slider, or enter a value in the box.
In VR-Forces you can create buildings and cultural feature objects from the Entity Palette that look like similarly named props in the 3D view. Cultural features are not the same things as props. Props are saved as part of the terrain. Cultural features are saved as part of the order of battle. They are a mechanism for placing objects into a scenario for visualization or simulation purposes.
Where to search: A terrain patch, such as an OpenFlight terrain, often references multiple files that define models that are incorporated into the geometry of the terrain. VR-Forces lets you specify the external files from which to extract props or you can specify a search expression that looks in all referenced files. If you select a referenced file, the process is quicker because VR-Forces searches for props only in the specified file.
What prop type to use: You can select a prop type from a list, specify a type of your choice, or let VR-Forces auto-generate prop types. If you choose Auto Generate, VR-Forces makes the prop type match the name of the referenced file. For example, a prop extracted from the file Bridge_Arch_Stone.flt would be given the prop type Bridge_Arch_Stone.medf.
Model definition to use: You can select a model definition from a list, or choose Use Extracted Geometry. If you accept the default value, Use Extracted Geometry, VR-Forces creates props using the geometry in the terrain patch. For example, if you chose Trees.flt as the referenced file, VR-Forces creates props using the tree geometry in that file.
VR-Forces extracts props only from the selected terrain patch. If your terrain has multiple terrain patches, you must repeat the procedure for each terrain patch from which you want to extract props.
For an example of how to extract props from a terrain patch, please see “Extracting Props from a Terrain,” on page 63-20.
To extract props from a terrain:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Extract Props page (Figure 55-16).
In the Terrain Patches box, select the terrain patch from which you want to extract props.
To extract props by specifying external files, select the Extract References tab. To extract props using a search expression, select the Advanced tab.
If you chose the Extract References tab, in the External References list, select the files from which you want to extract props.
If you chose the Advanced tab, type the search expression in the Search Expression box. Select the Regular Expression check box if you are using a regular expression.
i VR-Forces uses perl regular expression syntax.
Optionally, in the Prop Type box, select the type that you want to assign to the extracted props or type a prop type.
Optionally, in the Model Definition box, select the model definition that you want to apply to the extracted props.
A feature layer source file contains information about point, line, or areal features. Feature information is stored in a table in which each row is a feature and each feature is defined by the values in an arbitrary number of columns. To add a prop from a feature layer, you must build a rule that specifies the column headings and values for the feature you want to import. Then you must associate a prop type and model definition with the prop. You also must specify whether or not to ground clamp the prop.
Please see “Add Props,” on page 63-10 for an example of adding props from a feature layer.
To add a prop from a feature layer:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Add Props page (Figure 55-17).
In the Feature Layers list, select the feature layer from which you want to import the props.
Click the Add button ( ) to the right of the Field/Value window (Figure 55-17). The Build Field/Value Pair dialog box opens (Figure 55-18).
Figure 55-18. Build Field/Value Pair dialog box
In the Field list, select a field. Fields are the column headings in the feature defini- tion.
In the Value list, select a value. Values are one or more values from the definition table that are available for the column heading.
It is your responsibility to understand the feature definitions for the features that you want to import as props.
Click OK. The Field/Value pair is added to the window (Figure 55-19).
Add additional Field/Value pairs as needed to define the prop that you want to add.
In the Prop Type list, select the prop type to assign to the prop you want to add.
In the Model Definition list, select the model definition you want to use for this prop.
In the Ground Clamp box, specify whether or not to ground clamp this prop.
Optionally, set the rotation.
Click Execute Rule. The prop is extracted from the feature layer and is listed in the History window.
To view a list of the props in the terrain:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Edit Existing Props page (Figure 55-20).
Expand the list to view the entries under a particular type of prop.
To select a prop, click it in the window or select it in the list of props on the Terrain Settings dialog box, Edit Existing Props page.
Press Ctrl+click to select multiple props.
You can set the opacity of props. This can be useful if you want to see what is inside a building or behind a prop. Figure 55-21 illustrates a building at two levels of opacity.
100% 40%
To set a prop’s opacity:
Choose Settings Terrain. The Terrain Settings dialog box opens.
In the list of props select the props whose opacity you want to change, or select a prop in the window. The Opacity slider is enabled.
Slide the Opacity slider to the right to increase opacity. Slide it to the left to decrease opacity.
You can quickly set a prop to be fully transparent or opaque.
To make a prop fully transparent, right-click the prop and on the popup menu, choose Make Transparent.
To make a transparent prop fully opaque, right-click the prop and on the popup menu, choose Make Opaque.
Every prop has a type. Props are organized by type in the list on the Edit Existing Props page.
To change a prop’s type:
Choose Settings Terrain. The Terrain Settings dialog box opens.
In the list of props, select the props whose type you want to change.
Select a prop type from the Prop Type list, or type a new type name. The selected props are moved to the new prop type in the Props window.
You can change a prop’s position and orientation. You can change the orientation of multiple props at the same time without affecting their position. However, if you select multiple props and change position, they are all placed in the same position.
To change a prop’s position or orientation:
Choose Settings Terrain. The Terrain Settings dialog box opens.
In the list of props, select the prop whose position or orientation you want to change.
To change position, type or select new values in the X, Y, or Z boxes.
To change the orientation, type or select new values in the Yaw, Pitch, or Roll boxes.
You can change the model definition used to render a prop. For information about model definitions, please see Chapter 81, Model and Element Definitions. For an example of changing a prop’s model definition, please see “Test the Model Mapping,” on page 3-12.
To change a prop’s model definition:
Choose Settings Terrain. The Terrain Settings dialog box opens.
In the list of props, select the prop whose model definition you want to change.
In the Model Definition list, select a model definition. The selected props are rendered using the new model definition.
Composing Terrains — Specifying Simulation Ocean Settings
VR-Forces can determine the depth of the ocean floor from:
Underwater polygons, if present.
Feature data, such as S-57 data.
If a terrain has underwater polygons, VR-Forces always automatically uses that data. You can enable and disable use of feature data that sets the ocean depth. If you have both types of data, VR-Forces uses the shallowest depth of the two types of data for any given point.
You can also specify that VR-Forces use a fixed depth for any area that does not have underwater polygons or feature data.
Changing the simulation ocean setting is not a dynamic change. After changing the settings, you must save the terrain to an MTF file and reload the scenario.
To specify ocean depth:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Simulation Ocean Settings page (Figure 55-22).
To enable or disable use of feature data, select or clear the Use Sounding Point Data check box.
To specify the ocean depth for areas that do not have underwater polygons or feature data, type a value in the Sea Floor text box.
Save the terrain.
Composing Terrains — Specifying Simulation Ocean Settings
Reload the scenario.
56. Paged and Streaming Terrains
This chapter explains how to use terrain servers for paging and streaming terrains. It also provides information about preparing paged terrains for use with VR-Forces.
Connecting to Terrain Servers 56-2
Adding Terrain Server Connections 56-4
Connecting to Terrain Servers through a Proxy 56-5
Loading MetaFlight Terrains 56-5
Preprocessing Paged Terrains 56-6
Manually Paging-In Terrain 56-6
Displaying Information About Paged and Streaming Terrains 56-7
Displaying Information about Feature Paging 56-9
Displaying Additional Terrain Paging Information 56-10
Configuring Terrain Paging for the Back-End 56-12
VR-Forces supports the osgEarth libraries for creating terrains from remote or local data sources (Figure 56-1). Terrain servers are configured in earth (.earth) files. They support streaming of terrain data and are, therefore, ideal for displaying terrains that have large amounts of data.
Figure 56-1. Geocentric terrain
You can manipulate streamed terrains with the keyboard and mouse and can save them as an MTF terrain for quick loading.
VR-Forces includes several terrain server configurations for VR-TheWorld Online, a server hosted by VT MAK. You must have an internet connection to connect to these servers. It also includes server configurations that stream terrain files included with VR- Forces. These servers, such as, Local World.earth and SanLuisObispo-Topo.earth, are examples of how you can use earth files to load local data.
!
!
Integration of osgEarth into VR-Forces allows you to connect to data sources. However, it does not provide a license to use any data sources. It is your responsibility to comply with the licensing provisions of any site to which you connect.
Paged and Streaming Terrains — Connecting to Terrain Servers
“Creating a Terrain with an Earth File,” on page 63-14, is a tutorial that shows how to create a terrain server connection that serves local data.
When you view a geocentric terrain and move the observer more than 6 million meters or so from the earth’s surface, the view is forced to focus toward the center of the earth. The practical effect of this mode is that the left and right movement keys orbit the observer around the earth, rather than moving the entire earth to the left or right.
To connect to a terrain server:
Choose New Scene. The current terrain closes.
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Terrain Contents page (Figure 56-2).
Click Add Terrain Server. The Add Terrain Server dialog box opens (Figure 56-3).
Select a server from the Servers list. The dialog box displays information about the selected terrain server. It is not editable.
Click Connect. If the terrain data is available (remote sources might not always be accessible), it is displayed.
You can save a terrain server as part of a terrain. For details, please see “Saving a Terrain,” on page 55-4.
You can add additional terrain server connections to the list provided with VR-Forces. Terrain server connections are configured in XML files according to the requirements of the osgEarth libraries. The server configurations included with VR-Forces are examples of what you can do. We recommend that you add new servers by copying an existing configuration that is similar to what you want and then editing it to point to your data. (Chapter 57, Editing Earth Files, provides a brief introduction to earth file syntax.)
“Creating a Terrain with an Earth File,” on page 63-14, is a tutorial that shows how to create a terrain server that serves local data.
Paged and Streaming Terrains — Loading MetaFlight Terrains
OSG_CURL_PROXYPORT. Specifies the proxy port.
OSGEARTH_CURL_PROXYAUTH=username:password. Specifies the user name and password for the proxy.
When you load a MetaFlight file, VR-Forces is actually loading many individual Open- Flight files. If file caching is enabled, VR-Forces caches the OpenFlight files to disk in a quick-loading, encrypted format so that the files can load more quickly the next time you load the terrain. The cached files are handled the same way that any other cached files are handled. For details, please see “Configuring File Caching,” on page 61-2.
Geometry files referenced by a MetaFlight file must be in OpenFlight format, and not in Vega Prime's binary format (.vsb). MAK’s terrain libraries do not support .vsb files.
Paged and Streaming Terrains — Preprocessing Paged Terrains
For example, if a TerraPage terrain references /externals/tree.flt, preprocessing creates a file called /externals/tree.medf. When VR-Forces loads the terrain, it loads the MEDF version instead of the OpenFlight version.
We recommend that you preprocess all data to minimize load times and maximize run- time performance. For details about the medfTool, please see “Compressing Model Files,” on page 83-27.
Terrain page-in areas are created just like any other tactical graphic area. You can create them as the scenario progresses or you can include them in plans so that the terrain gets paged in when you know the scenario will need it. You can also attach a terrain page-in area to a simulation object to ensure that terrain in front of the simulation object gets paged in.
Terrain page-in areas are supported for paged IVE files and supported versions of the MetaFlight format.
i Terrain page-in areas only affect the back-end.
To create a terrain page-in area:
Open the Tactical Graphics Palette.
In the Categories list, select Control Objects.
In the Force list, select the force you want this area to be assigned to.
In the list of control objects, select Terrain Page-in Area.
Create the area as described in “Creating Objects,” on page 16-3.
By default, when you enable the display of terrain paging information, VR-Forces displays the portions of the terrain that are paged into the back-end. In Figure 56-5, green spheres represent the area that is paged in. Red spheres represent area that is not paged in. In Figure 56-5, green squares show the tiles that have been paged in as a simu- lation object moves over the terrain. If you are debugging a terrain and need help using this feature, please contact support@mak.com.
Drawing of paged terrain tiles is done using shared memory. Therefore, you can draw them only if the front-end and back-end are running on the same computer.
Figure 56-4. Paged-in terrain
You can display different information by entering commands on the back-end console.
When you display terrain paging information, you can also display the features that are loaded in the back-end. You specify which features to draw using console commands, as described in “Displaying Additional Terrain Paging Information,” on page 56-10. We recommend that you display features this way only in Plan View mode.
!
!
Enabling display of terrain paging information can introduce stability problems. It should only be enabled for debugging terrain.
To enable or disable display of terrain paging information, choose Settings
Terrain Paging Information Terrain Paging Areas.
Similar to the information you can display about paged terrain, you can display infor- mation about features as they are paged in. Figure 56-6 shows feature paging informa- tion from the inset area of the S57-NavalPathPlanning example scenario.
Figure 56-6. Feature information
!
!
Enabling display of feature paging information can introduce stability problems. It should only be enabled for debugging terrain.
To display feature paging information, choose Settings Features Paging Informa- tion feature. where feature is an option on the pull-right menu.
i The list of features to be viewed changes as features are paged in.
You can display additional terrain paging information by entering commands on the back-end console. You can also display information about feature sets if they are present. Table 56-1 lists the commands and their results.
Table 56-1: Terrain paging information commands
Command Result
Command Result
features config Print queries and transforms from featureconfig.txt. For
details about feature configuration, please see Chapter 62,
Configuring Feature Data.
features draw feature_set_inde x ...
Draws the feature sets specified by the list of feature set indexes. Separate the indexes by spaces.
features help Prints the syntax of feature commands.
features info Prints generic information about the feature sets, such as the number of paged in features and the coordinate system.
features list Lists all feature sets. The index of each set is used on the
commands that take lists of feature sets.
features pageout Pages out all unused feature tiles.
features print
index [number]
terrain drawmode
mode
Prints the feature sets as text. Optionally, specify the maximum number of features to print.
Specifies a bitmask that controls what information to display, as follows:
0 — Turn off information display.
1 — Display polygons (Figure 56-7).
2 — Display collision object bounding boxes (paged terrains) (Figure 56-8).
4 — Display spheres (paged terrains).
8 — Tile extents (streaming terrains).
12 — Show spheres for paged terrain and tiles for streamed terrain (the default).
15 — Display all terrain paging information.
terrain PSG Prints the contents of the scene graph to the console. You can display the same information in the front-end by opening the Scene Graph Nodes Panel.
pageout Pages out all tiles. Tiles that are needed are then paged back in.
terrain save
filename
Saves the paged-in tiles to an MTF file. This is useful for quickly and easily saving a portion of a large terrain to a smaller database. The default filename is simTerrain.mtf.
Table 56-1: Terrain paging information commands
Command Result
Command Result
pbv Prints page bounding information to the console.
terrain addlayer
layer
Displays information in the layer specified by layer. Devel- opers can write plug-ins to create new layers and add keywords to display them. The timer layer, included with VR-Forces causes the console to display how long it takes to perform terrain intersections. This information can be useful when diagnosing performance issues.
Figure 56-8. Collision objects display
To execute a console command:
Open the back-end console.
Type the command. You can type commands even if the console is displaying status messages. It remembers what you typed.
Press Enter.
You can configure terrain paging for the back-end in
./appData/settings/vrfSim/terrainOptions.mtl. Of particular note, you can configure the total number of triangles to be paged in at any one time. If the number of triangles exceeds this threshold, VR-Forces begins to page out triangles based on the priorities described in “Using Large Terrain Databases,” on page 52-7. The parameters that you can configure are described in comments in the file. (To configure terrain paging in the front-end, use the procedures described in “Loading MetaFlight Terrains,” on
This chapter provides an introduction to the syntax of Earth files.
Including External Files into Earth Files 57-5
Loading Multiple DTED Files 57-6
Adding Feature Layers to an Earth File 57-8
Configuring Point Features 57-10
Configuring Linear Features 57-11
Configuring Areal Features 57-12
Using Cut-in Sites for High Resolution Insets 57-14
Using the Boundary Generation Tool 57-15
Configuring Elevation Data for CDB 57-17
Configuring Image Data for CDB 57-19
Differential Processing of Elements and Attributes 57-21
Differential Processing of model Elements 57-22
Streaming Buoys and Beacons 57-23
Specifying Model Definitions for Streamed Buoys 57-24
Modeling Buoys Using Texture Atlases 57-27
Configuring Streaming Beacons 57-28
Editing Earth Files
Configuring Streamed Navigation Lights 57-29
Configuring Seasonal Buoys and Beacons 57-30
Generating Signal Sequences 57-31
An earth file is an XML format configuration file used to display terrain databases using osgEarth. The file format is documented at http://docs.osgearth.org/en/latest/. The information in this chapter supplements the information on the osgEarth web site. In particular, it explains how to configure streaming features, for which there is no GUI in VR-Forces.
i VR-Forces only supports geocentric terrains in earth files.
The following is an example of a simple earth file. It has one image layer and one eleva- tion layer:
<map name="earth" type="geocentric" version="2">
<!--Load a simple base image of the world-->
<image name="World Imagery" driver="gdal">
<url>../../data/Terrain/World/Imagery/World4km.tif</url>
</image>
<!--Load a folder full of terrain data as an elevation source-->
<heightfield name="World Elevation" max_data_level="16" max_level="16" driver = "gdal">
<!--To load the files in a directory, just point the URL to a directory instead of a file-->
<url>../../data/Terrain/World/Elevation/earthnew/w001001.adf</url>
<tile_size>32</tile_size>
</heightfield>
<model name="Country-Names" driver="feature_geom">
<features name="Country-Names" driver="ogr">
<url>../../data/Terrain/World/Features/world.shp</url>
</features>
<styles>
<style type="text/css"> Country-Names {
text-provider: annotation; text-content: [cntry_name]; text-priority: [pop_cntry]; text-halo: #3f3f7f; text-font: arial.ttf; text-size: 16;
text-remove-duplicate-labels: true; altitude-clamping: terrain-drape;
}
</style>
</styles>
</model>
<options>
<lighting>true</lighting>
<elevation_interpolation>triangulate</elevation_interpolation>
<terrain first_lod="1">
<min_tile_range_factor>4</min_tile_range_factor>
<skirt_ratio>0.1</skirt_ratio>
Editing Earth Files — A Simple Earth File
</terrain>
</options>
</map>
Table 57-1 describes the XML elements in the file and their attributes.
Table 57-1: Earth file elements and attributes
Element | Attribute | Description |
<!-- --> | Comment block. | |
map | Root level element. All other elements must be in the map block. | |
name | The name of the map. | |
type | The projection. VR-Forces only supports geocentric terrains, which can be specified as geocentric or globe. | |
version | The VR-TheWorld Server version. | |
image | Specifies an image layer. | |
name | The name of the layer. | |
driver | The driver to use to fetch tiles, for example, TMS, WMS, or GDAL. | |
url | The location of the files. This could be a web address or a local path. | |
heightfield | Specifies an elevation layer. | |
name | The name of the layer. | |
driver | The driver to use to fetch tiles, for example, TMS, WMS, or GDAL. | |
url | The location of the files. This could be a web address or a local path. | |
model | Base element for specifying a feature layer. For more information, please see “Adding Feature Layers to an Earth File,” on page 57-8. | |
name | Name of the model element. This can be any text. | |
driver | Driver to use for creating models. | |
options | Specifies options that affect the entire map. For more information, please see “Earth File Options,” on page 57-21. |
Earth files can include external files. This can make management of complex terrains easier. The included files must be XML files. There are two ways to include external files, the xi:include element and use of earth file templates.
The following example shows how to use xi:include:
<map name="readymap.org" type="geocentric">
<xi:include href="readymap_imagery.xml"/>
<xi:include href="readymap_elevation.xml"/>
</map>
When you reference a document using xi:include, it can only contain a single XML node, for example:
<image>
...
</image>
Since using an xi:include element for each node that you want to import might require many such elements, you can include multiple nodes in a single file by using earth file templates, an alternative include format. Use the syntax {% include filename %}. This syntax is used in some of the earth files shipped with VR-Forces. The following lines are from MAK Earth (online).earth:
<!-- Boston area models -->
{% include vrtheworld-streaming.buildings-boston.xml %}
<!-- Hawaii area models -->
{% include localdata.hawaii-maritime-navigation.xml %}
{% include vrtheworld-streaming.buildings-oahu.xml %}
{% include vrtheworld-streaming.airport-hnl.xml %}
The included XML files are located in the same directory.
!
!
In an earth file, if you comment out an include line that uses the {% include filename %} syntax, the included file must not have any comments or it will not be processed properly. This can result in terrain errors that are not easily diagnosed. Files included with the xi:include syntax do not have this restriction.
Editing Earth Files — Supported Drivers
Drivers are software components that allow you to load one or more types of terrain data. MAK has not tested all of the drivers supported by osgEarth. VR-Forces supports the following drivers:
tms
gdal
composite
feature
ogr
feature_geom
feature_custom
wfs
aglite.
You can load multiple DTED files from an earth file. To do so, in the heightfield element, specify a directory instead of a specific file, for example (from SanLuisObispo- Topo.earth):
<heightfield name="SanLuisObispo Elevation" driver = "gdal">
<url>../../data/Terrain/SanLuisObispo/Elevation</url>
<extensions>dt0;dt1;dt2</extensions>
...
</heightfield>
The extensions element lets you specify which files to load based on their file exten- sions. If you do not include an extensions list, the GDAL driver tries to load every file in the directory.
Editing Earth Files — Processing Streamed Data
./importConfig/registrant_feature_list.csv.
For example, in registrant_feature_list.csv, it states that the processor for SpeedTree trees, speedTreeManager, is mapped to Vegetation. In MAK Earth (online).earth, SpeedTree trees are configured as follows:
<model name="trees" driver="feature_custom">
<features name="Vegetation" driver="wfs">
The feature name is Vegetation. This means that it will be processed by the speedTree- Manager.
Similarly, the featureDataBroker, which is responsible for creating streamed buoys, beacons, and the lights and marks that might be attached to them, is mapped to s57- data and dynamicFeatures. (Processors can be mapped to more than one feature type.) Examples of using this processor are:
<model name="LateralBuoysUS5HA52M" driver="feature_custom" enabled="true">
<features name="s57-data" driver="ogr">
and
<model name="TaxiwayLights" driver="feature_custom">
<features name="dynamicFeatures" driver="ogr">
registrant_feature_list.csv file is fully commented and provides additional information about this scheme.
You can add the following types of features to a terrain:
Point features, such as trees, buoys, and buildings.
Linear features, such as roads and waterways.
Areal features, such as forests (areal trees), bodies of water, and extruded buildings. You can add the XML for feature layers to an earth file.
Feature layers are added to an earth file using the model element. The following example shows the hierarchical relationships of a model element and its sub-elements. Table 57-2 describes the model element, its attributes, and some of its sub-elements. (A particular model element may not have all of the sub-elements described.)
<model>
<features>
<url></url>
</features>
<layout>
<tile_size_factor></tile_size_factor>
<level></level>
</layout>
<styles>
<library>
<url></url>
</library>
<style></style>
<selector></selector>
</styles>
<lighting></lighting>
</model>
Table 57-2: model element attributes
Element Attribute Description
Element Attribute Description
model Base element for specifying a feature layer.
name Name of the model element. This can be any text. driver Driver to use for creating models.
vrfsim:enabl ed
Optional. For use in terrains used by VR-Forces if the simulation engine needs a different value for an attribute than that used by the front-end. If present, it is ignored by VR-Vantage and the VR- Forces front-end. For details, please see “Differen- tial Processing of model Elements,” on
page 57-22.
The features and layout elements specify how to get and load the feature data. The features block is mandatory. layout is optional.
features Specifies source of data. name Name of the element.
Table 57-2: model element attributes
Element | Attribute | Description |
driver | Driver to use to get the data. | |
url | Location of the feature data. | |
layout | Specifies how to load the data. | |
tile_size_factor | The data specified in the features element gets cut into tiles. This attribute specifies how aggressively to tile it. | |
level | name | The level specifies the level (LOD) beyond which not to display the features. |
max_range | Distance beyond which the feature is not displayed. | |
selector | class | Specifies the type of feature. |
styles | The styles element and sub-elements specify how to render the scene. This element is manda- tory. | |
library | A texture library. | |
name | Name of the texture library. | |
url | The location of the library. | |
style | A specific style. The name, which precedes the curly brace ({) can be any text you want. For infor- mation about the attributes that you can specify in a style, please see http://docs.osgearth.org/en/- latest/references/symbology.html. | |
lighting | Specifies whether or not to enable lighting. Usually true. |
When you load a file using the OGR driver (specified in the feature element), the layer name the name of the file (minus the extension). Other files (like S-57) can have multiple layers, and the names are decided by a format-specific algorithm. For example, an S-57 file has an enumerated list of layer names.
Point features, such as trees, use the model element. The following code, from MAK Earth (online).earth, adds point trees:
<model name="Alamoana point trees" driver="feature_custom">
<!-- streaming point trees -->
<features name="Vegetation" driver="ogr">
<url>../../data/Terrain/Hawaii/Features/AlaMoanaVegetationP.shp</url>
<typename>5</typename>
</features>
<layout>
<tile_size_factor>3</tile_size_factor>
</layout>
<styles>
<style type="text/css"> Vegetation {
marker: "Trees" + [veg] + "ST" ;
marker-scale: 1; marker-placement: vertex; altitude-clamping: terrain;
altitude-resolution: 0.00008583068847656250;
altitude-offset: 0;
}
</style>
</styles>
<clustering>True</clustering>
<lighting>true</lighting>
</model>
Linear features, such as roads, rivers, or railways, use the model element. The following code, from MAK Earth (online).earth, configures roads:
<model name="Oahu_Roads" driver="feature_geom" overlay="true" enabled="false">
<features name="Roads" driver="wfs">
<url>http://vr-theworld.com/vr-theworld/features/wfs</url>
<typename>55</typename>
</features>
<!-- Sets the name property on each geometry to the value of the "name" attribute -->
<feature_name>[name]</feature_name>
<!-- Appearance details -->
<style type="text/css"> Oahu_Roads {
stroke: #ff0000; stroke-width: 10.0;
altitude-offset: 10;
}
</style>
</model>
Areal features, such as forests, use the model element. The following code, from MAK Earth (online).earth, configures a forest with three types of trees:
<!-- Forest -->
<model name="trees" driver="feature_custom">
<features name="Vegetation" driver="wfs">
<url>http://vr-theworld.com/vr-theworld/features/wfs</url>
<typename>7</typename>
</features>
<layout>
<tile_size_factor>3</tile_size_factor>
<crop_features>true</crop_features>
<level max_range="8000" class="trees-1"> </level>
<level max_range="2000" class="trees-2"> </level>
<level max_range="1000" class="trees-3"> </level>
</layout>
<styles>
<style type="text/css"> trees-1 {
marker: "TreesNorwaySpruceST"; marker-placement: random;
marker-density: 800;
marker-scale: 1; altitude-clamping: terrain; altitude-resolution: 0.0001;
marker-random-seed: 1;
}
trees-2 {
marker: "TreesColoradoBlueSpruceST"; marker-placement: random;
marker-density: 800;
marker-scale: 1; altitude-clamping: terrain; altitude-resolution: 0.0001;
marker-random-seed: 2;
}
trees-3 {
marker: "TreesAmericanElmST"; marker-placement: random;
marker-density: 800;
marker-scale: 1; altitude-clamping: terrain; altitude-resolution: 0.0001;
marker-random-seed: 3;
}</style>
</styles>
<clustering>true</clustering>
<lighting>true</lighting>
</model>
Editing Earth Files — Extruded Buildings
If you are simulating in an urban environment, you want your terrain to have realistic 3D buildings. However, modeling hundreds or thousands of buildings by hand would be an arduous and expensive task. osgEarth can extrude buildings from areal features and apply textures to them to create a realistic environment with relatively little work. Publicly available GIS data that has footprint and height data can provide the input.
The following code (from MAK Earth (online).earth) adds extruded buildings to the terrain:
<!-- Extruded buildings Oahu -->
<model name="buildings" driver="feature_geom">
<!-- Streamed buildings -->
<features name="buildings" driver="wfs">
<url>http://vr-theworld.com/vr-theworld/features/wfs</url>
<typename>65</typename>
</features>
<layout>
<tile_size_factor>3</tile_size_factor>
</layout>
<styles>
<library name="us_resources">
<url>http://vr-theworld.com/vr- theworld/filemanager/download/public/Library/catalog.xml</url>
</library>
<style type="text/css"> buildings {
extrusion-height: [hgt2d]; extrusion-flatten: true; extrusion-wall-style: building-wall;
extrusion-roof-style: building-rooftop; extrusion-random-seed: 1;
altitude-clamping: terrain; altitude-resolution: 0.0001;
}
building-wall {
skin-library: us_resources; skin-tags: building; skin-random-seed: 1;
fill: #ffffff;
}
building-rooftop {
skin-library: us_resources; skin-tags: rooftop; skin-tiled: true;
skin-random-seed: 1; fill: #ffffff;
}
</style>
</styles>
<lighting>true</lighting>
<cluster_culling>false</cluster_culling>
</model>
For descriptions of the elements in a model block, please see Table 57-2.
Users of terrain servers, such as VR-TheWorld Server, often want to add high resolution sites of particular interest while using the lower resolution terrain provided by the terrain server for the rest of the world. You can add a high resolution terrain patch to a terrain server, but it overlays the terrain provided by the server and this can cause unex- pected visual problems. Ideally, you should cut out the relevant areas of terrain provided by the server and add your high resolution terrain to the cut out area. For example, the VR-Forces terrain MAK Earth (online).mtf has two terrain patches, MAK Earth (online).earth, which provides the base terrain from VR-TheWorld Server, and
./data/Terrain/Hawaii/Geometry/OpenFlightAlaMoana/AlaMoanaModifiedGeocen- tricProxy.osg, which is a locally stored high resolution inset.
The mask element lets you cover the base terrain data with your hand-modeled data. A mask element in an earth file looks similar to the following:
<mask name="HonoluluRunway26R-8L-mask" driver="feature" >
<features driver="ogr">
<geometry>
POLYGON((-157.91489143 21.32914026 3.016, -157.91525638
21.32914026 3.016, -157.91666238 21.32912541 3.016, -157.91697822
21.32934847 3.016, -157.91709263 21.32968744 3.016, -157.91709263
21.32968744 7.016, -157.91709263 21.32968744 11.016, -157.91709263
21.32968744 15.016, -157.91710262 21.32968706 15.016, -157.91697822
21.32934847 16.016, -157.91709263 21.32968744 16.016, -157.91710262
21.32968706 15.016))
</geometry>
</features>
</mask>
VR-Forces includes a tool, the osgEarth Boundary Generation Tool, that can calculate the geometry of an OpenFlight file. To cut out a section of terrain from the terrain server, add a mask element to the earth file. Use the output from the boundary tool for the data in the geometry element.
Table 57-3 describes the mask element and its sub-elements.
Table 57-3: mask element
Element | Attribute | Description |
mask | Element for cutting in geometry. | |
name | Name of the mask. | |
driver | The driver to use. | |
features | List of features in the mask. | |
driver | The driver to use. OGR reads raw vector feature data from shapefiles and other formats. |
Editing Earth Files — Using Cut-in Sites for High Resolution Insets
Table 57-3: mask element
Element | Attribute | Description |
geometry | Specifies the 3D boundaries of the site. You must know this information. | |
geometry_url | The location of the file with the feature data. |
The Boundary Generation Tool takes an OpenFlight file and calculates the bounding geometry of the file. It returns the coordinates in a text file. The general process of cutting in a site is as follows:
Run the Boundary Generation Tool against an OpenFlight file.
Insert the output of the boundary generation tool in a mask element in your earth file. (For details about mask elements, please see “Using Cut-in Sites for High Resolution Insets,” on page 57-14.)
Load the terrain.
Add the FLT file as a terrain patch.
Save the terrain.
The output from the Boundary Generation Tool tool, in boundary.txt or the output file you specify, looks similar to the following:
POLYGON((-157.91489143 21.32914026 3.016, -157.91525638 21.32914026
3.016, -157.91666238 21.32912541 3.016, -157.91697822 21.32934847
3.016, -157.91709263 21.32968744 3.016, -157.91709263 21.32968744
7.016, -157.91709263 21.32968744 11.016, -157.91709263 21.32968744
15.016, -157.91710262 21.32968706 15.016, -157.91697822 21.32934847
16.016, -157.91709263 21.32968744 16.016, -157.91710262 21.32968706
15.016))
The first two vertices are the latitude and longitude. The third vertex is the height, in meters. The remainder of the vertices map the outline of the geometry.
To run the boundary generation tool:
Open a console window.
Change directory to ./bin64.
Run the tool:
osgearth_boundarygen [--out file_name --no-geocentric
--convex_hull --verbose --view --precision precision
--tolerance tolerance] model_file
Table 57-4 describes the options.
Table 57-4: osgEarth Boundary Generation Tool command-line options
Option Description
Option Description
--convex_hull Calculate a convex hull instead of a full boundary.
model_file The input model file.
--no-geocentric Skips geocentric reprojection. Use for flat databases.
--out file_name Specifies the output file for boundary geometry. Default:
boundary.txt.
--precision precision Specifies the number of significant digits in the output coordinates. Default: 12.
--tolerance tolerance Specifies the tolerance for combining similar vertices
along a boundary. Default: 0.005.
--verbose Prints progress messages to the console.
--view Show the result in a 3D window.
Because MAK uses osgEarth to load CDB databases, you have the same flexibility with CDB databases that you do with other database types. For example, you can:
Use streaming data (from VR-TheWorld Server), or other source imagery to build a skirt around a CDB inset.
Place an OpenFlight inset into a CDB database.
Add lights, buildings, forests, grass, and other clutter on top of an existing CDB database.
VR-Forces includes an example CDB terrain – Test-CDB-SanLuisObispo.mtf, which uses Test-CDB-SanLuisObispo.earth.
Elevation data is configured in an elevation element. The following is a sample
elevation element (from Test-CDB-SanLuisObispo.earth):
<elevation name="cdb_elevation"
driver="CDB" cdb_dataset="1" cdb_component_selector1="1" cdb_component_selector2="1"
cacheid="camppend3-cdb-elevation" >
<cache_policy usage="read_write"/>
<cdb_root>../../data/Terrain/SanLuisObispo/Geometry/CDB</cdb_root>
</elevation>
Table 57-5 describes the attributes in the elevation element.
Table 57-5: elevation attributes for CDB
Attribute Description
Attribute Description
Name The name of the dataset you are loading in osgEarth.
driver To load CDB, you must use the CDB driver.
cdb_dataset Specifies the CDB dataset to read. For elevation, it must be 1. Optional. Default = 1.
cdb_component_selector1 Specifies the first CDB component selector to use.
Table 57-5: elevation attributes for CDB
Attribute Description
Attribute Description
cdb_component_selector2 Specifies the second CDB component selector to use.
Optional. Default=1. For a list of selectors, please see Table 57-6.
cdb_cache_file Specifies how many CDB tiles to keep in memory while building an OSG tile. Default = 20.
cdb_max_lod Specifies the maximum LOD of this dataset. Set this value if you have a CDB database that is larger than 500 geocells. For example if you have the CDB World Wide database you can set this value to 0. This causes the CDB Driver to pre-parse all the LOD folder. If the value is not set (default) the driver reads the CDB to find the maximum LOD of the elevation dataset.
Optional.
cacheid Specifies where to save cache files if caching is enabled.
cdb_root Specifies the top folder of the CDB database.
Table 57-6 describes the values you can use for the cdb_dataset and cdb_component_se- lector attributes.
Table 57-6: elevation sub-dataset code for CDB
Dataset Code (Dxxx) | Component Selector1 (Sxxx) | Component Selector2 (Txxx) | Description |
1 | 1 | 1 | Primary elevation. |
1 | 1 | 2 | Primary elevation control. (Depre- cated in CDB 3.2.) |
1 | 1 | 3 | Primary alternate elevation. |
1 | 2-99 | 1 | Subordinate elevation. (Depre- cated in CDB 3.2.) |
1 | 2-99 | 2 | Subordinate elevation control. (Deprecated in CDB 3.2.) |
1 | 100 | 1 | Subordinate bathymetry. |
1 | 100 | 2 | Subordinate alternate bathym- etry. |
1 | 101 | 1 | Subordinate tide elevation. |
The following example shows how to add bathymetry to a CDB terrain. Adding bathymetry lets you add dynamic ocean.
<elevation name="cdb_elevation"
driver="CDB" cdb_dataset="1"
cdb_component_selector1="100" cdb_component_selector2="1" cdb_cache_file="10" cacheid="camppend3-cdb-elevation" >
<cdb_root>.../../data/Terrain/SanLuisObispo/Geometry/CDB</cdb_root>
<offset>true</offset>
</elevation>
To load imagery from a CDB terrain, use the image element, as in the following example (from Test-CDB-SanLuisObispo.earth):
<image name="cdb_imagery"
driver="CDB" cdb_dataset="4" cdb_component_selector1="1" cdb_component_selector2="1"
cacheid="camppend3-cdb-imagery" >
<cache_policy usage="read_write"/>
<cdb_root>../../data/Terrain/SanLuisObispo/Geometry/CDB</cdb_root>
</image>
Table 57-7 describes the attributes in the image element.
Table 57-7: image attributes for CDB
Attribute Description
Attribute Description
Name The name of the dataset you are loading in osgEarth.
driver To load CDB, you must use the CDB driver.
cdb_dataset Specifies the CDB dataset to read. For imagery, it must be 4. Optional. Default = 1.
cdb_component_selector1 Specifies the first CDB component selector to use.
cdb_component_selector2 Specifies the second CDB component selector to use.
Optional. Default=1. For a list of selectors, please see Table 57-8.
cdb_cache_file Specifies how many CDB tiles to keep in memory while building an OSG tile. Default = 20.
Table 57-7: image attributes for CDB
Attribute Description
Attribute Description
cdb_max_lod Specifies the maximum LOD of this dataset. Set this value if you have a CDB database that is larger than 500 geocells. For example if you have the CDB World Wide database you can set this value to 0. This causes the CDB Driver to pre-parse all the LOD folder. If the value is not set (default) the driver reads the CDB to find the maximum LOD of the elevation dataset.
Optional.
cacheid Specifies where to save cache files if caching is enabled.
cdb_root Specifies the top folder of the CDB database.
Table 57-8 describes the values you can use for the cdb_dataset and cdb_component_se- lector attributes.
Table 57-8: image sub-dataset code for CDB
Dataset Code (Dxxx) | Component Selector1 (Sxxx) | Component Selector2 (Txxx) | Description |
4 | 1 | 1 | Yearly VSTI (Visual Spectrum Terrain Imagery) representation. |
4 | 2 | 1 | Alternate Spring representation. (Deprecated in CDB 3.2.) |
4 | 2 | 2 | Alternate Summer representa- tion. (Deprecated in CDB 3.2.) |
4 | 2 | 3 | Alternate Fall representation. (Deprecated in CDB 3.2.) |
4 | 2 | 4 | Alternate Winter representation. (Deprecated in CDB 3.2.) |
4 | 3 | 1-12 | Alternate Monthly representa- tion. |
4 | 4 | 1-4 | Quarterly VSTI representation. |
4 | 5 | 1 | Subordinate VSTLM. (Corre- sponds to the terrain light maps draped (orthographically) over the terrain skin derived from the Primary Terrain Elevation Dataset. It may be single-channel monochrome or 3-channel color image.) |
Editing Earth Files — Differential Processing of Elements and Attributes
An earth file can have option elements that affect the entire map. Table 57-9 describes the option elements.
Table 57-9: option element
Element | Attribute | Description |
lighting | Enables or disables lighting for the entire map. This is usually true. | |
elevation_interpolation | Specifies how OSG interprets elevation between grid posts. If you are using VR- Forces or visualizing a VR-Forces simulation, set this to triangulate to ensure correlation. | |
cache | Specifies caching for terrain data. | |
type | The type of caching to use. | |
path | The location of the data cache. |
There are times when you want the front-end and back-end to process terrain differ- ently. You can specify different values for elements and attributes with the vrfsim: syntax. Anyplace that VR-Forces sees vrfsim: when it processes an earth file, it uses that value for the back-end. For example, if you want different values for the name attribute in a model element, specify it as follows:
<model name=”front_end_name” vrfsim:name=”back_end_name”>
To specify differential elements, the element names must be the same and be the only two elements of that name in the scope of the earth file or an element block. For example, the following code would mean use the <trees> element in the front-end and the <vrfsim:trees> element in the back-end:
<trees>
...
</trees>
<vrfsim:trees>
...
</vrfsim:trees>
Editing Earth Files — Differential Processing of Elements and Attributes
You can enable or disable differential processing within model elements. By default, all model elements except those that use the simple driver have differential processing disabled.
To enable differential processing add vrfsim:enabled=”true” to the model
element.
The following example of differential feature processing is from MAK Earth (online).earth. It is the section used to extrude buildings. vrfsim:enabled is set to true. The value for the typename attribute is applied to front-end processing and the value for the vrfsim:typename attribute is applied to back-end processing.
<model name="buildings" driver="feature_geom" vrfsim:enabled="true">
<features name="buildings" driver="wfs">
<url>http://vr-theworld.com/vr-theworld/features/wfs</url>
<typename>105</typename>
<vrfsim:typename>109</vrfsim:typename>
</features>
If a model element uses the simple driver, it uses the value of the enabled attribute to determine whether or not to use differential processing (in other words, there is no default setting). If you want to explicitly enable or disable differential processing, add vrfsim:enabled with the appropriate value to the model element. Then add an attribute element in which the attribute name is prefaced by vrfsim: as in the example in this section.
Streamed features (including buoys) are organized into layers. In the earth file, the names in the styles block specify the layer the streamed features will belong to. By default, VR-Forces defines seven layers for buoys. They correspond to the different buoy layers in an S-57 file. These layers are named LateralBuoys, SafeWaterBuoys, ISDBuoys, RegulatoryBuoys, InstallationBuoys, CardinalBuoys, and SpecialPurpose- Buoys.
The configuration file ./appData/importConfig/s57_layer_list.csv specifies which style names in an earth file correspond to recognized streamed feature types. The file currently contains two lines. The first starts with the keyword “Buoys” and is followed by a comma-separated list of all the style names that will be recognized (and streamed in) as buoys. The second line starts with the keyword “Beacons” and is followed by the list of recognized beacon styles. They can be anything you like, but need to correspond with whatever style names you use in the earth file.
The following is an example of a style block for a buoy (Special Purpose Buoys):
<model name="buoys" driver="feature_custom">
<features name="Special Purpose Buoys" driver="ogr">
...
</features>
<layout>
...
</layout>
<styles>
<style type="text/css">
<!-- | | | This is the layer name -->
<!-- v v v -->
SpecialPurposeBuoys {
......
}
</style>
</styles>
Within each style block, you specify the model definition to use for a streamed buoy or beacon. Since buoys and beacons have different styles and within each style have different colors and markings, VR-Forces can map the S-57 data to buoy and beacon models in the following ways:
Specify a model definition for each type of buoy. Buoy color and numbering is the same for all buoys.
Generate a model definition name using a pattern and S57 attributes.
Specify a model definition for a unique buoy based on the buoy's name.
Use a texture atlas to model buoys. (A texture atlas is an image that has sub-images that can be referenced by a coordinate system. Those sub-images can be applied to 3D models.)
All of these methods are supported by VR-Forces and are described in this section. However, VR-Forces uses texture atlases for all streaming buoys and beacons.
To specify the model definition for a type of buoy, you specify it as the marker name:
<styles>
<style type="text/css"> SpecialPurposeBuoys {
marker: "BuoysSpecialPurpose" ;
...
In this case, the model definition “BuoysSpecialPurpose” is used for all buoys streamed in for that SpecialPurposeBuoys layer.
This approach is the simplest way to specify model definitions for buoys.
Instead of specifying a model definition, you can have VR-Forces build a model defini- tion using the buoy’s attributes. This approach is more complex than specifying one model definition for a type of buoy, but it is more flexible. You can accommodate many variations of a given type of buoy without having to specify many model definitions.
Buoy attributes can be strings or enumerated values (such as shape (BOYSHP), color (COLOUR), and color pattern (COLPAT)).
The following code results in model definitions like “Buoys352”.
<styles>
<style type="text/css"> SpecialPurpose {
marker: "Buoys" + [BOYSHP] + [COLOUR] + [COLPAT];
Creating and managing model definitions with coded numbers in this way is difficult. Therefore, VR-Forces provides a mechanism to map the numeric attribute values to strings.
The enumerated value-to-string mappings are in ./appData/importConfig/s57_at- tr_map.csv. You can change them to any strings that you want to use. Given this infor- mation, you can specify your model definition as a pattern and provide the enumerated attribute values. VR-Forces uses them to decode and build the requested model defini- tion. The pattern and attribute values are specified as a colon (:)-separated list of the following form:
"pattern:Attribute1=value:Attribute2=value" ...
The pattern itself indicates where attribute values should be replaced using ‘[Attribute]’ substrings. For example, consider an input string such as:
"Buoys[COLOUR][BOYSHP]:COLOUR=5:BOYSHP=3"
The default mappings for COLOUR and BOYSHP in s57_attr_map.csv are as follows:
BOYSHP,,Nun,Can,Spherical,Pillar,Spar,Barrel,Super,Ice COLOUR,,White,Black,Red,Green,Blue,Yellow,Grey,Brown,Amber,Violet,Orange
,Magenta,Pink COLPAT,,HorizontalStriped,VerticalStriped,DiagonalStriped,Squared,
Striped,BorderStriped
Therefore, the model definition would be BuoysBlueSpherical, since the enumerated COLOUR value ‘5’ (the fifth value in the list) is mapped to “Blue”, and the BOYSHP value ‘3’ is mapped to “Spherical”. Some of these attributes, such as COLOUR, may be lists of enumerated values. The strings for enumerated lists are concatenated. The following input string:
"Buoys[BOYSHP][COLOUR][COLPAT]:COLOUR=3,1:BOYSHP=2:COLPAT=2
results in the model definition “BuoysCanRedWhiteVerticalStriped”.
To generate the input string like the one above from an earth file, you would use:
marker: "Buoys[BOYSHP][COLOUR][COLPAT]"
+ ":COLOUR=" + [COLOUR]
+ ":BOYSHP=" + [BOYSHP]
+ ":COLPAT=" + [COLPAT]
The order that the actual attribute/value pairs are encoded (after the pattern) does not matter.
Many buoys have some form of one to three numbers, letters, or both that appear on the buoy itself. S-57 does not provide an attribute that indicates what this symbol is, but it is usually found at the end of the OBJNAM attribute, such as “Boston South Channel Buoy 13” or “President Roads Junction Lighted Buoy PR”. If the OBJNAM attribute is provided, the model definition builder tries to extract this symbol. It must be 3 characters or less, and be all numerics, all capital letters, or a mix of the them. You can add this to a model definition pattern using the [DESIGNATOR] substring, for example:
marker: "Buoys[BOYSHP][COLOUR][COLPAT][DESIGNATOR]"
+ ":COLOUR=" + [COLOUR]
+ ":BOYSHP=" + [BOYSHP]
+ ":COLPAT=" + [COLPAT]
+ ":OBJNAM=" + [OBJNAM]
This code, when streaming in “Boston South Channel Buoy 13”, would result in a model definition of “BuoysCanGreen13”, since the BOYSHP attribute for that buoy maps to “Can” and COLOUR attribute to “Green”.
There may be cases where you want to use a specific model definition for a particular buoy. The buoy might be a special landmark that needs to be recognizable. The file appData/importConfig/s57_modeldef_by_name_map.csv contains a list of buoy names (the OBJNAM attribute) and model definition pairs. If the OBJNAM attribute value is provided in the marker string and if it matches one of the buoy names in s57_model- def_by_name_map.csv, then the specified model definition is used instead of a generated definition.
This approach is more complex than specifying a model definition per type of buoy or building one from attributes. It requires understanding how to use texture atlases.
However, this method allows you to have a large number of buoys in a scene with a wide variety of colors, patterns, and designators using a very limited number of models. This dramatically reduces the scene complexity (thereby increasing frame rate) when you use instancing. This is the approach that VR-Forces uses for all buoys and beacons it ships with.
Each buoy shape (can, pillar, nun, and so on) is a separate model. Each model has a texture atlas that has all the different colors and patterns needed for that buoy shape. In the marker field (in the model statement) a simple model definition pattern is used:
Buoy[BOYSHP]
The other attributes are passed in the same fashion as described in “Generating a Model Definition Name for a Buoy,” on page 57-24 when mapping attributes to model defini- tion substrings:
marker: "Buoys[BOYSHP]"
+ ":BOYSHP=" + [BOYSHP]
+ ":COLOUR=" + [COLOUR]
+ ":COLPAT=" + [COLPAT]
+ ":OBJNAM=" + [OBJNAM] ;
In this example, all the attributes are mapped to strings, but the COLOUR and COLPAT strings are used to look up the appropriate uv texture coordinate offsets for the buoy. The texture-uv mapping file has the same name as the buoy model plus the extension dtxc (for example, PillarBuoy.dtxc and Can.dtxc).
The .dtxc files can support multiple atlases that may be used on the same model. VR- Forces uses multiple atlases for buoys with topmarks, and beacons with daymarks and topmarks. (For information about topmarks and daymarks, please see “Streaming Daymarks,” on page 57-30 and “Streaming Topmarks,” on page 57-31.) The model definition for the buoy specifies a key (found in the .dtxc file) to be used for the main texture (mainTextureKey) and for the topmark's texture (topmarkTexturekey).
The following code is an example of a beacon model block:
<model name="beacons" driver="feature_custom" enabled="true">
<features name="Lateral Beacons" driver="ogr">
<!-- From S-57 data -->
<ogr_driver>S57</ogr_driver>
<url>../../data/Terrain/Massachusetts/Features/US5MA10M.000</url>
<layer>BCNLAT</layer>
</features>
<layout>
<tile_size_factor>3</tile_size_factor>
</layout>
<styles>
<style type="text/css"> LateralBeacons {
marker: "Beacons[BCNSHP]"
+ ":BCNSHP=" + [BCNSHP]
+ ":COLOUR=" + [COLOUR]
+ ":COLPAT=" + [COLPAT]
+ ":PERSTA=" + [PERSTA]
+ ":PEREND=" + [PEREND]
+ ":OBJNAM=" + [OBJNAM] ;
marker-scale: 1; marker-placement: vertex; altitude-clamping: terrain;
altitude-resolution: 0.00008583068847656250;
altitude-offset: 0;
}
</style>
</styles>
</model>
Model definitions for beacons work the same way as for buoys. They are configured in s57_attr_map.csv. It can contain enumeration mappings for any enumerated S-57 attri- bute that you want to use to create model definitions. Default values are in s57_de- faults.csv. This contains the default name and default model definition for each style group specified in s57_layer_list.csv. The delivered s57_defaults.csv contains:
# If the final model definition generated does not exist, one of these model definitions will be used
Buoys,DefaultModelDefinition,BuoysGreenPillar1 Beacons,DefaultModelDefinition,BuoysRedPillar2
# If the feature has no name, use one of these Buoys,DefaultName,Unnamed Buoy Beacons,DefaultName,Unnamed Beacon
Each model that has a light should have a comment-tagged switch for choosing a light group of the specified color. Each light in turn has a switch for turning the light itself on or off. We use the tag @dis light_color to tag a color switch, with values 0-3 corresponding to white, green, red, and yellow. The switch to turn lights off and on is
@dis navigation_lights.
VR-Vantage streams in light data using model blocks similar to those used for buoys and beacons. You can apply style names. light_layer_list.csv controls which styles will be read. Massachusetts S-57 (online).earth uses a single style name for all lights, Navigation- Lights. The following example shows a model block for a light:
<model name="LightsUS5MA10M" driver="feature_custom" enabled="true">
<features name="s57-data" driver="ogr">
<!-- From S-57 data -->
<ogr_driver>S57</ogr_driver>
<url>../../data/Terrain/Massachusetts/Features/US5MA10M.000</url>
<layer>LIGHTS</layer>
<!-- From a Shape file -->
<url>../../data/Terrain/Massachusetts/Features/US5MA10M/LIGHTS.shp</url>
</features>
...
<styles>
<style type="text/css"> NavigationLights {
marker: "COLOUR=" + [COLOUR] + ":SIGSEQ=" + [SIGSEQ] + ":EXCLIT=" + [EXCLIT];
marker-scale: 1; marker-placement: vertex; altitude-clamping: terrain;
altitude-resolution: 0.00008583068847656250;
altitude-offset: 0;
}
</style>
</styles>
</model>
Since we are not building model definitions, we do not need to map enumerated values to strings. However, we do map S-57 light colors to the colors that we support. This mapping is in light_attr_map.csv. VR-Vantage associates light controllers with other streamed features based on the S-57 or shape file locations of the lights and features, as follows:
If the COLOUR attribute is provided, the attached light controller sets the light color using the light color switch.
If the SIGSEQ attribute is provided, the light is turned on and off according to the specified sequence.
If the EXCLIT attribute is provided, the light controller enables or disables the light based on daylight and fog conditions.
The light color switch and light switch values can be changed by specifying different ones through the API, specifically using:
de.scene().terrain().navigationLightManager(). setLightColorSwitchNumber()
and
de.scene().terrain().navigationLightManager().setLightSwitchNumber()
Seasonal buoys and beacons are supported. Include the PERSTA/PEREND attributes in the earth file as part of the marker field, and buoys and beacons will only appear during the correct season. Example:
marker: "Buoys[COLOUR][COLPAT][BOYSHP][DESIGNATOR]"
+ ":BOYSHP=" + [BOYSHP]
+ ":COLOUR=" + [COLOUR]
+ ":COLPAT=" + [COLPAT]
+ ":PERSTA=" + [PERSTA]
+ ":PEREND=" + [PEREND]
+ ":OBJNAM=" + [OBJNAM] ;
VR-Forces supports streamed daymarks for beacons. A limited number of daymark models and textures are provided as examples. Massachusetts S-57 (online).earth has a model statement to stream daymarks from the Boston Harbor S-57 data. As with buoys and beacons, the model entry specifies a style name (Daymarks), which corre- sponds to a layer specified in daymark_layer_list.csv. OSGEarth models that use the feature_custom driver and have a style name that is in the layer list file, are processed as daymarks. S-57 attribute values can be mapped using the daymark_attr_map.csv file.
The beacon models provided with VR-Forces contain multiple daymark placard shapes (Diamond, Square, and Triangle), which are selected based on the TOPSHP attribute. The TOPSHP attribute is mapped to '0', '1', or '2', which are the switch values for the diamond, square, or triangle shaped marks. Other attribute values, including TOPSHP, COLOUR, COLPAT, and CATSPM are used to look up UV coordinates in the model's texture atlas using a uv-texture coordinate mapping file similar to the one described for buoys. The mappings are in ./data/Objects/Beacons/daymark.dtxc. These daymark shapes, plus textures provided, represent all the daymarks attached to beacons in Boston Harbor. The model definition for daymarks includes a parameter that speci- fies a string key to use in the .dtxc file (“daymarkTextureKey”).
Topmarks can be streamed in and attached to buoys and beacons similarly to daymarks. The shape is determined by the TOPSHP attribute. The attribute is mapped to a switch value using the topmark_attr_map.csv file. Textures for the topmarks can be selected from a texture atlas similarly to buoys and daymarks. The model definition for a buoy or beacon that needs to map attributes to uv-texture coordinates using that model’s .dtxc file will have a string key (topmarkTextureKey) that identifies the mapping entries in the file that pertain to the topmark texture atlas.
The S-57 attribute SIGSEQ (signal sequence) specifies the flashing sequence that a navigational aid light on a buoy or beacon displays. These sequences (along with color) are used to distinguish among different buoys and beacons at night. However, this is not a required S-57 attribute. If the SIGSEQ attribute is not present, VR-Vantage tries to generate a signal sequence using the LITCHR (light characteristic), SIGPER (signal period) and SIGGRP (signal group) attributes for the most commonly seen sequences.
As part of the class responsible for generating these sequences, the VR-Forces API includes a virtual function for each sequence type that is not implemented, so that a developer can implement it. The assumption is that not many of the other sequence types will be used, but it is data-specific. Once we know what sequences are needed for the S-57 data in use, it should be relatively straight-forward to implement those addi- tional sequence generation methods.
The class used to generate signal sequences is DtLightSignalSequenceGenerator, in the vrvCore library. DtLightSignalSequenceGenerator.h provides documentation, including which methods are implemented and which are not. To extend this class, a creator is provided, DtLightSignalSequenceGeneratorCreator, an extended instance of which can be registered through a plug-in with the display engine.
58. Generating Navigation Data
This chapter explains how to generate navigation data for use with VR-Forces.
Creating Navigation Areas 58-3
Editing a Navigation Area 58-4
Reverting Edits to Navigation Area 58-5
Displaying Navigation Areas 58-5
Removing a Navigation Area 58-5
Generating Navigation Data 58-5
Generating Navigation Data for a Navigation Area 58-6
Using Newly Generated Navigation Data 58-8
Generating Navigation Data for Entities 58-9
Importing Navigation Areas and Navigation Data 58-10
Displaying Navigation Data 58-11
Opening Navigation Lab from an Information Dialog Box 58-12
Showing Simulation Object Movement in Navigation Lab 58-13
Generating Navigation Data — Introduction
The ability to generate navigation data is an extra-cost feature. VR-Forces includes navigation data for the terrains and entity models it includes. If you want to be able to generate navigation data for your terrains or models, you must purchase an additional license.
When you generate navigation data, the VR-Forces creates separate sets of navigation data, at various levels of detail, for specified profiles. VR-Forces includes profiles for lifeforms and ground vehicles. You can modify the profiles and add new ones. The navi- gation data is stored in separate directories where it can be accessed by multiple terrains, if needed.
Navigation data is generated as follows:
Load the terrain on which you want to generate navigation data or load a scenario that uses that terrain.
Create a navigation area.
Generate the navigation data.
Save the terrain.
Start a new scenario or save and reload the existing scenario.
Generating Navigation Data — Creating Navigation Areas
Navigation areas define areas on the terrain for which you can generate navigation data. Navigation areas are rectangular areas that are aligned to the North/South axis. The maximum size of the area on which you can generate navigation data depends on the raster precision value used to generate it. If you reduce the precision of navigation data, creating a sparser graph, the size of the maximum area increases. The maximum size for a navigation area using the default values is 20 km by 20 km. (Raster precision is configured in ./vrforces4.5/appData/settings/vrfSim/navigationProfiles.mtl.)
You can create multiple navigation areas on a terrain.
To create a navigation area:
Open a scenario or a terrain on which you want to generate navigation data.
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Navigation Areas page (Figure 58-1).
Click New. The cursor changes to create mode and shows a box that represents the navigation area. The default size is 500 m by 500 m. The Create Navigation Area tab is added to the window.
Click to place the lower left corner of the navigation area (Figure 58-2).
Generating Navigation Data — Creating Navigation Areas
In the Create Navigation Area dialog box, edit any of the properties of the naviga- tion area, including:
Name. (You cannot change the name of a navigation area after you create it.)
Length and Width. Edit these values to change the size of the navigation area.
Do not try to create an area larger than 20 km by 20 km unless you have changed the raster precision to support a larger area.
The type of navigation data to generate – for lifeform, ground platform, or both.
Click Create.
After you create a navigation area, you can edit any of its attributes except its name.
To edit a navigation area:
Open a scenario or a terrain that has the navigation area you want to edit.
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Navigation Areas page (Figure 58-1).
Select the navigation area you want to edit.
Click Edit. The Edit Navigation Area dialog box opens.
Make the change you want to make.
Click OK.
If you edit a navigation area, you can revert to the previous version of the area.
To revert an edited navigation area:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Navigation Areas page (Figure 58-1).
Select the navigation area you want to revert.
Click Revert.
To display navigation areas, choose Settings Navigation Areas, or click the Navi- gation Area button 
) on the Display Settings toolbar.
To remove a navigation area:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Navigation Areas page (Figure 58-1).
Select the navigation area you want to remove.
Click Remove.
To generate navigation data, you create navigation areas and then generate navigation data for them. A terrain can have more than one navigation area. Entities use advanced navigation within the areas and standard navigation if they move between them.
Generating navigation data can last from a few minutes to hours to days depending on the terrain complexity, the level of detail, and your computer’s processing power. Navi- gation data is saved to ./userData/navData in a directory that matches the name of the terrain on which it was generated.
./appData/settings/vrfSim/navigationProfiles.mtl. The configuration parameters are
explained in the file.
The profile that an entity uses for advanced navigation is specified in its OPE file. For example, Human.ope specifies use of the lifeform profile:
(navigation-parameters
(DtRwString navigation-profile "lifeform") (DtRwString navigation-method "shortcut")
)
The Navigation Areas page (Figure 58-1) displays the status for each navigation area:
Generated. Data has been generated.
Needs Generation. The navigation area needs to have navigation data generated.
You can generate navigation data for:
Selected navigation areas.
For all navigation areas that need to have navigation data generated.
For all navigation areas, including those that already have navigation data.
When you generate navigation data, the generator does not use the version of the terrain that is loaded into the simulation engine or GUI. It uses a separate version. Therefore, if you have made any changes to the terrain, for example by adding props, and you want them to be part of the updated terrain, you should save the terrain before you generate navigation data.
To generate navigation data:
Open a scenario or a terrain on which you want to generate navigation data.
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Navigation Areas page (Figure 58-1).
Select the navigation areas for which you want to generate navigation data.
Click Generate.
You are prompted to save the terrain before navigation data is generated.
Click Yes. The Navigation Area Path Generation dialog box opens (Figure 58-3). You can optionally view details of the generation process or cancel the process. When the navigation data is generated, the dialog box buttons redisplay. You are prompted to reload the scenario.
Click OK.
Click Finish.
Save the terrain. (File Save Terrain.)
To use the navigation data, reload the scenario.
If you schedule multiple navigation areas for navigation data generation by clicking Generate All or Regenerate All, you can remove areas from the generation queue. If you remove a navigation area for which you had already generated navigation data, its status returns to Generated. If you remove a navigation area that has not had navigation data generated, its status returns to Need Generation.
To remove a navigation area from the generation queue:
Select the navigation area in the Navigation Areas list.
Click Cancel Scheduled Generation.
You can cancel generation of navigation data while it is being generated for a navigation area. If you cancel generation of navigation data, the status for the navigation area changes to Needs Generation, even if you previously generated navigation data for this area.
To cancel generation of navigation data while it is being generated, do one of the following:
Select the navigation area in the Navigation Areas window and click Cancel Sched- uled Generation.
In the Navigation Area Path Generation dialog box, click Cancel NavArea n, where
n is the number of the area currently being generated.
To use newly generated navigation data, create a scenario that uses the terrain or open a scenario that uses that terrain. If you generate navigation data while a scenario is open, you must close the scenario, then open it again before you can use the navigation data.
Generating Navigation Data — Generating Navigation Data for Entities
When you generate navigation data for an entity, it gets saved in the vrfSim/navData directory for the SMS. It is saved immediately, regardless of whether or not you save changes to the SMS.
To generate navigation data for an entity:
Start the Simulation Object Editor, as described in “Starting the Simulation Object Editor,” on page 64-4.
Load the SMS for the entity you want to edit, for example EntityLevel.sms.
In the object list, select the entity for which you want to generate navigation data.
In the attribute panel, select Use Detailed Geometry in Simulation Engine (Figure 58-4).
If you have not specified geometry for this entity, click Select and select the appro- priate geometry file. (For complete details, please see “Adding Object Geometry to an Entity,” on page 65-14.)
Click Generate. The Generating Navigation Data dialog box opens.
Specify the platform types for which you want to generate navigation data.
Generating Navigation Data — Importing Navigation Areas and Navigation Data
Click Generate. VR-Forces generates navigation data (Figure 58-5). When the process finishes, the Cancel button changes to read Complete.
Click Complete.
When you generate navigation data for a navigation area, navigation area configuration files and the navigation data itself are saved to ./userData/navData. For example, the configuration file for the Ala Moana navigation area provided with VR-Forces is Ala Moana.navGenConfig and Ala Moana.navRuntimeConfig.
You can import the navigation area and navigation data into other terrains that have the same coordinate systems and cover the same area of the earth. When you import a navi- gation area, it is imported with the status Generated.
To import a navigation area and its associated navigation data:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Navigation Areas page (Figure 58-1).
Click Import Navigation Area. A file browser window opens.
Navigate to the directory for the navigation area that you want to import and select the .navRuntimeConfig configuration file for the navigation area.
Click Open. The navigation area is added to the terrain.
VR-Forces includes Autodesk® Gameware Navigation Lab software (Navigation Lab), a tool that lets you view navigation data. It also lets you connect to a simulation and watch entities move about on the terrain.
You can view navigation data for navigation areas and for the object geometry on enti- ties. You can open Navigation Lab and use its menus to select the navigation data to view or you can open it directly from an Information dialog box.
Figure 58-6 displays the navigation data for VR-Village.
Figure 58-6. Navigation data display
i Autodesk® Gameware Navigation Lab is not supported on Linux.
To display navigation data by opening it in Navigation Lab:
On the Start menu, choose MAK Technologies VR-Forces 4.5 Tools Naviga- tion Lab.
Navigation Lab opens.
Choose File Open. A file browser opens.
To view navigation data for a terrain, navigate to a terrain under ./user- Data/navData. To view navigation data for an entity, navigate to a directory in
./data/simulationModelSets/EntityLevel/vrfSim/navData.
Select a file with the .NavData extension. The navigation data is displayed in the Navigation Lab window.
Navigation areas and entities that have object geometry and navigation data have a button on their Information dialog box that you can use to quickly display their naviga- tion data in Navigation Lab.
To open Navigation Lab from an Information dialog box:
Open the Information dialog box for the navigation area or entity for which you want to view navigation data.
Click the Navigation Lab button 
). The Launch Navigation Lab dialog box opens (Figure 58-7).
Follow the directions on the dialog box.
You can view simulation objects in Navigation Lab. This can help you analyze problems in navigation data, such as the inability of an entity to plan a path.
To view simulation objects in Navigation Lab:
Figure 58-8. Simulation objects represented in Navigation Lab
This chapter describes the dynamic terrain feature.
Introduction to Dynamic Terrain 59-2
Manually Changing the Terrain 59-2
Resetting Dynamic Terrain Changes 59-2
Removing Dynamic Terrain Damage 59-3
Creating Dynamic Terrain Areas 59-3
Dynamic Terrain Switch Types 59-3
Dynamic Terrain — Introduction to Dynamic Terrain
VR-Forces supports damage to buildings as the result of munition impact. It also supports the ability to open and close doors, windows, and other features. This feature depends on the presence of switch nodes and appropriate model states in the models that can be damaged or changed.
For details about how terrain is damaged, please see “Configuring Damage for Dynamic Terrain,” on page 72-28.
Typically, terrain changes will occur as the result of munition damage or actions of players in a scenario. For example, a character might open a door so that it can enter a building. However you can manually apply damage states or make other changes.
To manually change the state of a terrain object:
Choose Simulation Dynamic Terrain Add Changes. The Add Dynamic Terrain Changes dialog box opens. The cursor changes to a green circle that represents the area within which changes can be made.
Optionally, change the radius.
Click on the terrain or enter the location where you want to make changes. If there are any dynamic terrain models in that area they are listed in the list window.
For each option listed that you want to change, select the state you want from the list.
Click OK.
If you have made changes to the terrain by hand, you can reset those changes. Reset Changes also lets you remove damage created by a munition.
To reset dynamic terrain changes:
Choose Simulation Dynamic Terrain Reset Changes. The Reset Dynamic Terrain Changes dialog box opens. The cursor changes to a green circle that represents the area within which changes can be made.
Optionally, change the radius.
Click on the terrain or enter the location where you want to reset changes. If there are any dynamic terrain models in that area they are listed in the list window.
For each option listed that you want to change, select Reset in the list.
Click OK.
Dynamic Terrain — Dynamic Terrain Switch Types
You can remove terrain damage caused by munitions or by hand. Remove Damage does not affect changes to doors and windows.
To remove dynamic terrain damage:
Choose Simulation Dynamic Terrain Remove Damage. The Remove Dynamic Terrain Damage dialog box opens. The cursor changes to a green circle that represents the area within which damage will be removed.
Click on the terrain or enter a location in the dialog box.
Optionally, specify the radius around the location within which to remove damage.
Click OK.
If you disable the global dynamic terrain processor when you create a scenario, you can still enable dynamic terrain within dynamic terrain areas. (Global dynamic terrain processor is an option on the Advanced tab of the New Scenario dialog box. For details, please see “Creating a Scenario,” on page 7-3.)
Dynamic terrain areas are tactical graphics that are available on the Hazards/Obstacles Palette. You create them just like any other areal tactical graphic.
Table 59-1: Damage types and values
Type
Allowable Values
Description
Type
Allowable Values
Description
damage none, slight, moderate, destroyed
damage_structure none, slight,
moderate, destroyed
General terrain damage.
Damage specific to houses and buildings.
door open, closed The state of a door.
window open, closed The state of a window.
Dynamic Terrain — Dynamic Terrain Switch Types
60. Processing MetaFlight Files
To display MetaFlight files in VR-Forces, you must first process them. This chapter explains how to do so.
Building Efficient MetaFlight Terrains for VR-Forces 60-2
Processing MetaFlight Files for Use in VR-Forces 60-3
Splitting Datasets into Individual MetaFlight Files 60-3
Converting Virtual Texture Datasets to Tiled Textures 60-4
Using the mftTool to Process MetaFlight Files 60-6
Convert Geometry Grid Datasets with Tiled Textures 60-7
Convert Source Data into MEDF Format 60-7
Create an MTF File for the MetaFlight Terrain 60-8
Processing MetaFlight Files — Building Efficient MetaFlight Terrains for VR-Forces
VR-Forces can only load MetaFlight terrains built with certain tools. All MetaFlight files must be preprocessed by VR-Forces tools before they can be loaded. The following are recommendations for constructing MetaFlight terrains that can be processed and loaded into VR-Forces:
The MetaFlight terrain can contain one or more Geometry Grid Datasets (GGDS).
The MetaFlight terrain can contain one or more Virtual Texture Datasets.
The MetaFlight terrain can contain one or more Cultural Feature Datasets.
The MetaFlight terrain can be built in the following coordinate systems: Geodetic, Geocentric, UTM, or Flat Earth.
For the best conversion of Virtual Textures into a tiled texture GGDS, match every Virtual Texture layer with a geometry layer.
For optimal performance the GGDS should be set up in a Pyramid structure (Level 1: 1x1, Level 2: 2x2, Level 3: 4x4, and so on).
For optimal performance levels 1-4 should be made of FILE LOD GEOM tiles only. Do not put any children LOD GEOM tiles in these levels.
For optimal performance the terrain should be balanced so that any single FILE LOD GEOM is not too large and can be paged in real-time (based on machine speed and video card). In other words, keep any single file small.
For optimal performance any single FILE LOD GEOM should not contain too many LOD GEOM nodes as children.
Geometry Grid Tile size (in meters) should match Virtual Texture Tile coverage (in meters.)
For optimal performance limit the number of external references. This will reduce cull times. (For example, instead of having 10 individual buildings, externally refer- ence one city block with all 10 buildings.)
Processing MetaFlight Files — Splitting Datasets into Individual MetaFlight Files
Before you can load a MetaFlight file in VR-Forces, you must process it as described in this chapter. If you try to load an unprocessed MetaFlight file, VR-Forces displays an error message. If you run the MAK processing tools on a MetaFlight database that does not conform, an error message is sent to the console window.
To process a MetaFlight file, you must:
Convert source data into MEDF and MEIF format.
Split each dataset into its own MetaFlight file.
Convert geometry from using virtual texture datasets into using tiled textures. (If the terrain does not use virtual textures, you can skip this step.)
Use the VR-Forces terrain composition process to combine the MetaFlight terrain files and save them in MTF format.
Geometry files referenced by a MetaFlight file must be in OpenFlight format, and not in Vega Prime's binary format (.vsb). MÄK’s terrain libraries do not support VSB files.
MAK tools work on one Geometry Grid Dataset (GGDS) at a time. Some MetaFlight files contain multiple GGDSs, so each one has to be moved into its own file. It is your responsibility to understand the syntax of the MetaFlight file and to know whether or not you need to split up datasets.
To split datasets:
Create a copy of the original file for each dataset. Give each a name that identifies the dataset it contains.
Open each copy of the original file in a text editor.
In each file, delete all of the <GeometryGridDataset> XML element blocks except the one for the dataset you want to have in this file.
When you are finished, each MetaFlight file will have only one GGDS and possibly one or more Virtual Texture Datasets (VTDS).
The display engine does not handle virtual textures at runtime. Therefore you must convert the virtual texture datasets into tiled textures.
The syntax for mftTool is as follows:
mftTool -f filename [-c index -w index -l index -m string
-r path -x size -s directory -t filename -A -g -e -u
-p threads --extendLevelZero distance -v -h --]
Table 60-1 describes the command-line options.
Table 60-1: mftTool command-line options
(-- | --ignore_rest) Ignore all arguments after this one.
(-A | --regenerateAll) Forces the regeneration of all tiled textures. This
can be much slower and is needed less frequently if the virtual texture dataset does not change.
(-c | --col) index The column to convert, using a zero-based index.
(-e | --encryptImages) The tiled textures are generated in the MEIF file
format. If not specified the file format will be DDS.
--extendLevelZero distance Specifies the page-in range (in meters) of grid
(-f | --file) filename The name of the MetaFlight file that contains the GGDS.
Processing MetaFlight Files — Converting Virtual Texture Datasets to Tiled Textures
Table 60-1: mftTool command-line options
Option Description
Option Description
(-g | --generateFiles) Generate tiled textures from the virtual texture
and generate tiles in MEDF format from the FLT tiles that use the new textures. An MFT file is published. The output name will be equal to the MetaFlight file specified with the -f option with the string _medf appended to the end before the extension. For example, converting a file named yourTerrain.mft creates a new MetaFlight file named yourTerrain_medf.mft in the same direc- tory as yourTerrain.mft. If the generated tiled texture already exists, the file is not regener- ated. The -u and -g arguments are mutually exclusive.
(-h | --help) Displays usage information.
(-l | --level) index The level to convert, using a zero-based index.
(-m | --missing) string The missing texture placeholder.
(-p | --threads) threads Specifies the number of threads to run. Speci-
(-r | --searchDir) directory Adds a directory to the search path when
(-s | --subDir) directory The path to the substitution texture specified by
the VTDS. The arguments -s and -t are mutu- ally exclusive.
(-t | --vtFile) file The name of the MetaFlight file that contains
the VTDS. The arguments -s and -t are mutu- ally exclusive.
(-u | --publishMftOnly) Publish a new MetaFlight file that can be loaded
by VR-Forces. The output name will be equal to the MetaFlight file specified with the -f option with the string _medf appended to the end before the extension. Converting a file named yourTerrain.mft creates a new MetaFlight file named yourTerrain_medf.mft in the same direc- tory as yourTerrain.mft. The -u and -g argu- ments are mutually exclusive.
(-v | --version) Display version information and exit.
Table 60-1: mftTool command-line options
(-w | --row) index The row to convert, using a zero-based index.
(-x | --textureSize) size Specifies the maximum texture size to generate
in pixels per dimension. Larger textures use more memory and are slower to page in, but allow for greater virtual texture resolution.
If neither the generate (-g) or the publish only (-u) argument is specified, mftTool prints out information regarding the MetaFlight terrain.
mftTool -f C:\yourTerrain\yourTerrain.mft
-s C:\yourTerrain\ds200-vt-otw-virtual-texture -g -A -e
The following example shows how to process a terrain with two MetaFlight terrain files, one with the GGDS and one with the VTDS. In this case, the tiles also contain external references to other OpenFlight models.
mftTool
-f C:\yourTerrain\ds100-flight-terrain\ ds100-flight.mft
-t C:\yourTerrain\ds200-vt-otw-virtual-texture\ ds200-vt.mft-r C:\yourTerrain\textures
-r C:\yourTerrain\objects
-m C:\yourTerrain\MissingTexture.png -x 4096 -g
This creates a new MetaFlight file that references the new geometry grid dataset with virtual textures bound to it.
Processing MetaFlight Files — Convert Source Data into MEDF Format
The mftTool only needs to publish the MFT when the GGDS uses tiled textures. Cultural feature datasets are often built this way. These can be converted using the medfTool like all other files. The command syntax for the medfTool is described in “Compressing Model Files,” on page 83-27.
To only publish a new MetaFlight for the cultural dataset, do the following:
mftTool -f C:\yourTerrain\flt\ds7_culture_db5_build- ing_area_new-hier_cult\ds7_culture_db5_building.mft -u
-p 0
To convert a MetaFlight with tiled textures into a compressed format, use the medfTool, as follows:
medfTool -s C:\yourTerrain\flt\textures
-s C:\yourTerrain\flt\objects
--directory C:\yourTerrain\flt\ ds7_culture_db5_building_area_new-hier_cult -x flt
-m rgb -m rgba -m jpg -m bmp -p 0 -z 1
!
!
The medfTool should never be run on a directory that contains GGDS tiles that use Virtual Textures.
Many file formats, including OpenFlight files, are often slow to load, so it is best to convert them to the fast loading MEDF (MAK Encrypted Data Format) format. Do this for terrains that do not have virtual textures (it is done automatically when creating geometry grid datasets from virtual texture datasets) and on cultural feature datasets. This should be done on all data files being loaded, but is required for all external refer- ences used by MetaFlight terrains.
! You must convert the files to MEDF and MEIF before you run the mftTool.
To convert external references in separate directories:
medfTool -s C:\yourTerrain\flt\textures --directory C:\yourTerrain\flt\objects -x flt -m rgb -m rgba -m jpg
-m bmp -p 0 -z 1
To convert external reference textures that are in the same directory:
medfTool --directory C:\yourTerrain\flt\textures -m rgb
-m rgba -m jpg -m bmp -p 0 -z 1
Processing MetaFlight Files — Create an MTF File for the MetaFlight Terrain
Once you have processed all of the MetaFlight files, create an MTF file for the terrain.
Any missing models or white objects usually indicate missing external references. Fixing any missing search paths passed to the tools should resolve most problems.
To create an MTF file for the MetaFlight terrain:
Start VR-Forces.
Add each MetaFlight terrain as a terrain patch.
Save the terrain as an MFT terrain.
61. Terrain Performance and Configuration
This chapter covers miscellaneous issues that affect terrain performance and func- tioning.
Specifying the Location to Cache Terrain Server Data 61-3
Caching earth File Terrain Data 61-3
Caching earth File Terrain Data Offline 61-5
Enabling Texture Compression 61-6
Using Shader-based Effect Maps 61-7
Displaying DDS Textures Correctly 61-10
Flipping DDS Textures Globally 61-11
Displaying Terrain Intersection Lines 61-12
Converting OpenFlight File Texture Data 61-13
When file caching is enabled, VR-Forces stores information about the terrain and models in a format that enables it to be loaded quickly. This improves loading time the next time the cached objects are loaded. If caching is disabled, terrains and models must be loaded from their native formats, which may take longer.
When VR-Forces processes a request to load a a file, such as an external reference in a terrain, it checks the cache and the directory of the requested file for an MEDF version of the file. If it does not exist, it loads the file in the original format.
To enable or disable file caching:
Choose Settings Application. The Application Settings dialog box opens.
Select the File Caching Settings page (Figure 61-1).
Select or clear the Enable Accelerated File Loading check box.
When file caching is enabled, VR-Forces caches data from terrain servers in the default locations. You can override this by specifying alternative caching locations using the OSGEARTH_CACHE_PATH and VRFSIM_OSGEARTH_CACHE_PATH envi-
ronment variables. These environment variables interact as follows:
If you just set OSGEARTH_CACHE_PATH, then the front-end and back-end both use it. It overrides the cache element in the earth file.
If you set OSGEARTH_CACHE_PATH and VRFSIM_OSGEARTH_- CACHE_PATH then the front-end uses OSGEARTH_CACHE_PATH and the back-end uses VRFSIM_OSGEARTH_CACHE_PATH.
If you just set VRFSIM_OSGEARTH_CACHE_PATH the back-end uses that value, and the front-end uses the default cache location or the location specified in the earth file.
You can cache the terrain data in earth files to speed up loading terrain and to allow you to load terrains without connecting to a terrain server, either locally or over the internet. The osgearth_cache tool lets you cache imagery and elevation data offline. (For details, please see “Caching earth File Terrain Data Offline,” on page 61-5.) You can also generate cached data through the GUI. The advantage of caching data from the GUI is that you can cache imagery, elevation, and feature data and can use the mouse to specify the area to cache rather than needing to calculate the latitude and longitude, as required by osgearth_cache.
i It may take a very long time to generate the cache for large areas.
To generate cached data:
Load a terrain that uses an earth file.
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Terrain Contents page.
Click the osgEarth Cache button. The osgEarth Cache dialog box opens (Figure 61-2).
If you want to generate cached data for the entire terrain, make sure that the Specify Cache Area check box is cleared.
If you want to generate cached data for a portion of the terrain:
Select the Specify Cache Area check box.
Specify the latitude and longitude of a rectangle that defines the area you want to cache. You can do this by adjusting the sliders or entering values for the four values or you can draw a rectangle on the terrain.
To draw a rectangle on the terrain, click the left mouse button and release it to specify the upper left corner of the rectangle. Drag the mouse to define the cache area. Left-click again to specify the lower right corner.
Optionally specify the lowest LOD level and the highest LOD level.
Click Generate Cache.
VR-Forces includes a tool, ./bin64/osgearth_cache, that you can use to cache terrain data offline. When you need to use the terrain, the data will have already been cached. osgearth_cache caches imagery and elevation. It does not cache feature data. The syntax is as follows:
osgearth_cache --list file.earth | --seed file.earth
[--estimate --min-level level --max-level level
--bounds xmin ymin xmax ymax* --index shapefile --mp
--mt --concurrency --verbose]| --purge file.earth
where:
--list file.earth lists information about the cache in an earth file. If the earth file uses template syntax to include other files, you must append .template to the name of the file, for example, myfile.earth.template. If the file name has spaces, enclose it in parentheses.
--seed file.earth seeds the cache for an earth file. If the earth file uses template syntax to include other files, you must append .template to the name of the file, for example, myfile.earth.template. If the file name has spaces, enclose it in parentheses.
--estimate prints out an estimation of the number of tiles, disk space, and time it will take to perform the seed operation.
--min-level level specifies the lowest LOD level to seed. Default: 0.
--max-level level specifies the highest LOD level to seed. Default: highest available.
!
!
We strongly recommend that you specify --max-level and seed just the areas that you want.
--bounds xmin ymin xmax ymax specifies the geospatial bounding box to see, in map coordinates. You can include multiple instances of this option. Default: entire map.
--index shapefile tells osgearth_cache to use the feature extents in the speci- fied shapefile to set the bounding boxes for seeding.
--mp specifies use of multiprocessing to process the tiles. This is useful for GDAL sources because it avoids the global GDAL lock.
--mt specifies use of multithreading to process the tiles.
--concurrency specifies the number of threads or processes to use if --mp or
--mt are used.
--verbose displays the progress of the seed operation.
--purge file.earth purges a layer cache in an earth file. This command is interactive.
The following example caches a file named VR-TheWorldOnline.earth:
osgearth_cache.exe --seed ../userData/servers/VR-TheWorld- Online.earth --max-level 2
The following example caches a portion of a file named HawaiiLocalServer-mak.earth:
osgearth_cache.exe --seed ..\userData\servers\Local World Ala Moana.earth --max-level 18 --bounds
-162.0013879999999915 14.9985579999999992
-149.9985580000000027 25.0013879999999986
If you preprocess a CDB terrain, you must copy all of the directories created for the terrain from ./appData/cache to ./appData/cache/vrfsim.
When texture compression is enabled, textures are converted internally to a compressed format (DXT). Compressing textures decreases memory use and increases rendering performance.
To enable or disable texture compression:
Choose Settings Application. The Application Settings dialog box opens.
Select or clear the Enable Texture Compression On All Textures check box.
You can clear the file cache if you need to free disk space.
The cache is normally configured to be in ./appData/cache. You can delete files from this directory if you want to. The most likely reason to do this is if you load a terrain and realize that it should have had its DDS textures flipped, but has now been saved with them oriented the wrong way. You could delete the cache, then reload the terrain and toggle DDS Textures to the opposite setting.
To clear the file cache:
Choose Settings Application. The Application Settings dialog box opens.
Click Clear Accelerated File Loading Cache.
Effect maps are raster images that apply highly realistic textures to the terrain and models. By applying different types of effect maps to terrain and models, you can improve the visual qualities of your simulation without the overhead of high polygon counts.
VR-Forces supports the following types of shader-based effect maps:
Normal, or bump, maps. Normal maps give terrains the appearance of relief, such as a rocky landscape.
Specular maps. Specular maps affect the highlight color of objects.
Ambient occlusion maps. Ambient occlusion maps model areas that do not receive direct light, such as cracks and crevices and shaded areas of terrain and models. These areas are lit only by ambient light.
Reflection maps. Reflection maps affect the reflectivity of surfaces, such as windows. Reflection maps reflect objects in the sky, not the terrain.
Emissive maps. Emissive maps control the emissivity of whatever they are applied to based on the current ambient light values. The alpha channel is an ID that is set from 0-255. All the pixels that should light together (like a window, and perhaps a surrounding sill) should have the same ID. When the ambient light level drops below a given ID level, those pixels are emissive. Channel 2 (green) is used to indi- cate the intensity of the emissivity. These textures need to use a lossless compression scheme, such as PNG. LittlePond.mtf has sample emissivity textures on many of the houses.
Normal map: filename_NML.png
Ambient Occlusion map: filename_AO.png
Specular map: filename_SPC.png
Reflection map: filename_RFL.png
Emissive map: filename_EMM.png.
i The map code must be uppercase on Linux.
Terrain Performance and Configuration — Using Shader-based Effect Maps
To see the effect of effect maps, you must enable lighting. For details, please see Chapter 43, Lighting Effects.
VR-Vantage provides some shader debugging capabilities within its lighting shaders. The shaders are instrumented such that setting different flags (through uniforms) changes the behavior of the shader. Typically it changes fragment colors based on some parameter or parameters. Figure 61-3 shows a view of VR-Village with two different shader debug settings.
Bumpmap Normals Diffuse Light Figure 61-3. Shader component visualization
To debug shaders:
Choose Settings Display. The Display Settings dialog box opens.
Select the Render Settings page (Figure 61-4).
Select an option from the Component Visualization list.
Developers who are fine tuning shaders for terrain and object models do so by editing text files that configure the shaders. They can load their new shaders without shutting down VR-Forces.
To dynamically reload shaders:
Choose Settings Display. The Display Settings dialog box opens.
Click Reload Shaders.
Terrain Performance and Configuration — Displaying DDS Textures Correctly
DDS is a DirectX bitmap format that is often used for textures. DirectX expects the origin of the image to be at the top left corner. OpenGL expects the image origin to be at the bottom left corner. By default, VR-Forces assumes that images have the OpenGL orientation. However, sometimes images are not oriented properly and therefore you may have to tell VR-Forces to flip them.
You can change the DDS textures setting as follows:
On a per-model basis. (For details, please see “Flipping DDS Textures for a Model,” on page 83-21.)
When you add a terrain patch. (For details, please see “Adding Elevation Data (Terrain Patches) to a Terrain,” on page 55-5.)
As a global setting. (For details, please see “Flipping DDS Textures Globally,” on page 61-11.)
Terrain Performance and Configuration — Displaying DDS Textures Correctly
To enable or disable DDS texture flipping for all terrains:
Choose Settings Display. The Display Settings dialog box opens.
Select the Loader Settings page (Figure 61-5).
Select the Flip DDS Textures check box.
Click Close.
Terrain Performance and Configuration — Displaying Terrain Intersection Lines
You can display terrain intersector lines to help you debug problems with terrain perfor- mance.
To display terrain intersection Lines
Choose Settings Display. The Display Settings dialog box opens.
Select the Intersector Settings page (Figure 61-6).
Select the Draw Intersectors check box.
Optionally, set the duration of the intersector lines.
Optionally change the colors used for intersector lines.
Terrain Performance and Configuration — Converting OpenFlight File Texture Data
To provide soil characteristic data for VR-Forces, when the VR-Forces loads an Open- Flight terrain database, it tries to deduce soil type information from the names of the texture files that are usually associated with OpenFlight files.
By default, the VR-Forces tries to determine the soil types by looking for keywords, such as road, street, grass, water, and so on, in the name of the texture file. If this method does not adequately capture soil type information in the file you are importing, you can map the texture files to soil types in the surfChar.map file. This file is specific to each terrain. For an example, see ./data/terrain/Makland/Geometry/OpenFlight/surf- Char.map.
Table 61-1 lists the MAK soil types to which you can map the OpenFlight texture files.
asphalt | dryGround | orchards | shallowRiver |
boulder | forest | pavedRoad | shallowStream |
building | grass | rock | softSoil |
cultivatedFields | gravelRoad | sand | swamp |
deepLake | mud | shallowLake | tree |
deepRiver | ocean | shallowPond | USRailroad |
dirtRoad |
The surfChar.map file supports two methods of matching textures to soil types, substring match and regular expression. For a substring match, use the Match keyword and provide a string to match, as in:
Match HL_water ocean
VR-Forces will match textures with the string HL_water to the ocean soil type.
To use a regular expression, use the RegExprMatch keyword and provide a regular expression, as in:
RegExprMatch ^water.* ocean
VR-Forces will match textures that start with the string water to the ocean soil type.
The following is an example surfChar.map file:
SurfaceCharacteristicMap
{
Match | HL_water | ocean |
Match | Water_Ocean_Deep_Blue | ocean |
Match | Tree_Evergreen | tree |
Match | Tree_Canopy_Evergreen | forest |
Match | Road_Highway_Two-Lane_Asphalt | pavedRoad |
Match | Road_Street_Single-Lane | pavedRoad |
}
The center column in each entry is an OpenFlight texture. The right column is a MAK soil type.
The list of supported soil types is fixed. Therefore, you cannot add new soil types.
Earth files can contain many layers of elevation, imagery, and feature data. When you are debugging performance problems for a terrain that uses an earth file it can be helpful to turn off individual layers and see how that affects performance. You can do that with the osgEarth Profile dialog box.
In addition to seeing how enabling and disabling a layer affects performance, you change test the effect of changing the opacity of a layer and disabling lighting. You can only disable lighting for model layers (features area specified using the model element).
This feature is for use in debugging only. You cannot use it to configure different views of the terrain. Changes are not saved. The earth file is not edited.
If you want to filter out earth file layers and have the changes persist, use the Earth Layers page. For details, please see “Filtering Earth File Layers,” on page 53-12.
Terrain Performance and Configuration — Debugging Earth Files
To turn earth file layers on and off:
Load an earth file.
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Terrain Contents page (Figure 61-7).
In the terrain contents window, select the earth file that you want to debug.
Click osgEarth Profile. The osgEarth Profile dialog box opens (Figure 61-8).
Expand the list of the layers that you want to check.
Select a layer in the list. Clear the Enabled check box and see how performance changes.
To see the effect of lighting on a particular layer, clear the Lighting Enabled check box.
Optionally, change the opacity of a layer.
Repeat this process for each layer that you want to check.
Click Close.
This chapter explains how to update the feature data configuration file so that the simu- lation engine can understand feature data.
Specifying Different Feature Names for the Front-End and Back-end 62-2
Feature Configuration Attributes 62-4
Attribute Transformations 62-4
Transformations as Aliases 62-4
Transformations as Derived Attributes 62-5
Transformations as New Attributes 62-5
Writing Multiple Transforms to Account for Possible Failures 62-5
Source-Specific Configuration 62-5
Loading Source-Specific Configuration Files 62-6
Extracting Feature Data from GDB to Shapefiles 62-7
Converting S-57 Feature Data to Shapefiles 62-7
Configuring Aggregate-Level Movement Restrictions 62-9
Configuring Feature Data — Introduction
To use feature data correctly for simulation, the VR-Forces simulation engine must know some things about the feature data. For example, when an areal feature is loaded from a feature source, VR-Forces needs to know how to determine whether that feature is a building footprint, lake boundary, forest boundary, or something else entirely.
The simulation engine determines how features should be used by sending queries to the terrain database. The queries that VR-Forces uses are defined in
./appdata/settings/featureconfig.txt. Feature data is defined using attributes. Attributes
have names and values. If the feature data that you are using uses the attributes that VR-Forces knows about, it can process your terrain correctly. If not, you must edit featureconfig.txt so that VR-Forces can understand your data. The configuration file is commented. This chapter provides additional documentation about querying feature data.
As described in “Adding Feature Layers to an Earth File,” on page 57-8, feature layers are added to an earth file using the model element. The front-end uses the name attri- bute of the model element to determine what kind of feature layer is being added. In many cases, the back-end can use the same name to determine how to handle the feature data. However, there are some cases where the front-end needs to handle feature data differently from the back-end and needs to use a name that would cause the back- end to process the data incorrectly.
The back-end determines the name of the feature layer based on the following criteria:
If features come from the server:
If the vrfsim:layer element is included in the model, the back-end uses the name specified by vrfsim:layer.
If vrfsim:layer is not included, the back-end uses the value in the name
attribute.
If the features come from a local file (that is, they use the “ogr” driver):
If the vrfsim:layer element is included in the model, the back-end uses the name specified by vrfsim:layer.
If vrfsim:layer is not included, the ogr library picks the name.
The supported feature names are specified in ./appdata/settings/featureconfig.txt.
Configuring Feature Data — Named Queries
The following earth file snippet specifies the name “buildings”, which both the front- end and back-end would use:
<model name="buildings" driver="some_driver">
<features> ... </features>
</model>
The following earth file snippet specifies the name “special_buildings” and the
vrfsim:layer “buildings”:
<model name="special_buildings" driver="some_driver">
<features> ... </features>
<vrfsim:layer>buildings</vrfsim:layer>
</model>
In this case, the front-end loads feature data based on the name “special_buildings”. The back-end loads feature data using the name “buildings”.
The following earth file snippet specifies the ogr driver. The driver would choose the feature names.
<model name="special_buildings" driver="ogr">
<features> ... </features>
</model>
For more information about the vrfsim: syntax, please see “Differential Processing of Elements and Attributes,” on page 57-21.
MAK_BUILDING: (mak_layer="buildings") OR (mak_layer="BuildingsP") OR (DTDESCRIPTION = "Building") OR (DTFIDCODE = 181)
In this query definition, mak_layer, DTDESCRIPTION, and DTFIDCODE are attri- bute names. If a feature has one of these attributes with the specified value, VR-Forces knows to treat the feature as a building.
Please see ./appdata/settings/featureconfig.txt for information about query syntax.
Queries that begin with “MAK_” are referred to either in asimulation model set configuration, or in the VR-Forces code. Do not change the names of these queries.
Configuring Feature Data — Feature Configuration Attributes
When VR-Forces loads a feature in the simulation engine, it adds attributes that indi- cate where the feature came from. VR-Forces may add one or more of the following features:
MAK_LAYER. This attribute represents the source of the data – either the name of the file for features loaded from a local file, or the name of the feature layer in an earth file. In the example in “Named Queries,” on page 62-3, MAK_LAYER would match a file named BuildingsP.shp, for example, or an earth file feature layer named “buildings”.
MAK_EARTH_FILE. If the feature is loaded from an earth file, the file it was loaded from.
Create common names for attribute concepts, such as “width”, which may be named differently depending on the source.
Create new attributes whose value is derived from other attributes, which can be modified through configuration instead of in the code.
Add entirely new attributes to features that match the given query.
For example, the following code defines the attribute MAK_WIDTH:
Transform ALL: double MAK_WIDTH = [ width | w | wdt | gdb_width | dtwidth
| wid2d ]
This adds, to each feature matching the named query ALL, a new double attribute named MAK_WIDTH. The value of MAK_WIDTH will be the value of the first attribute found in the bracketed list.
Configuring Feature Data — Source-Specific Configuration
You can use transformations to create derived attributes – that is, attributes whose value depends on the value of another attribute. For example, the following line defines MAK_NUM_LANES, which depends on the width of a road:
Transform MAK_ROAD: int MAK_NUM_LANES = MAK_WIDTH / 4
This adds a new int attribute named MAK_NUM_LANES to each feature matching the named query MAK_ROAD. The value of this attribute is based on the value of MAK_WIDTH.
You can use transformations to add entirely new attributes – for example, to differen- tiate one way roads from two way roads. In this example, a query for one way road is created, and a new attribute MAK_ONEWAY is added to each feature that matches the query:
MAK_ONEWAYROAD: MAK_ROAD AND (ONEWAY = "yes" OR ONEWAY = 2)
Transform MAK_ONEWAYROAD: int MAK_ONEWAY = 2
By doing this, we can query the attribute MAK_ONEWAYROAD on any feature, and its existence will mean that the feature represents a one way road.
You can write multiple transforms for a particular feature if you anticipate that the preferred transform might fail. A transform might fail if it refers to a feature attribute that is not present in the feature data being processed. If you include multiple trans- forms in the file, they are processed in order until one is successful.
For example consider the following transforms:
Transform MAK_S57_DEPTH_AREAS: double MAK_MIN_DEPTH = DRVAL1 Transform MAK_S57_DEPTH_AREAS: double MAK_MIN_DEPTH = 0
This transform configures S-57 depth areas. The first transform uses the value of DRVAL1. If the data does not have the DRVAL1 attribute, it sets the depth to 0.
Since different sources of feature data can have different, even contradictory, definitions of the same data, you can create additional configuration files that exist alongside specific data sources.
Configuring Feature Data — Source-Specific Configuration
Whenever a feature source is loaded, VR-Forces looks for a configuration file that is specific to that source. The filename that it looks for depends on the source of the data. See featureconfig.txt for the details of source-specific configuration file loading by source type.
Source-specific configuration files can redefine queries in the main configuration file, so the main configuration file can be kept as simple as possible. In the following example, the terrain loaded points to two different .shp files, each with a different concept of a main road.
Test.mtf points to two different Shape files:
./data/Terrain/Test/Features/RoadL.shp. Any feature with the attribute "HIGHWAY" set to 1 is a main road.
./data/Terrain/Test/Features/MainRoads.shp. All features are main roads. Here is the definition of a main road in the main configuration file:
MAINROAD: MAK_ROAD AND MAK_NUM_LANES >= 4
To specify a different definition of MAINROAD for each source, two new configuration files can be created:
RoadL.mfc contains the following definition:
MAINROAD: HIGHWAY = 1
MainRoads.mfc contains the following definition:
MAINROAD: ALL
At runtime, these queries are combined, using the mak_layer attribute, to create a single definition of the MAINROAD query:
OR
AND
MAK_ROAD MAK_NUM_LANES >= 4
AND
MAK_LAYER = "RoadL" HIGHWAY = 1
MAK_LAYER = "MainRoads"
In this example it is possible to create this query entirely within
featureconfig.txt. Here the source-specific configuration is used for readability.
Configuring Feature Data — Converting S-57 Feature Data to Shapefiles
When you load feature data from a shapefile, it is used more efficiently than if you load it from a GDB file. (For details about loading feature data into a feature layer, please see “Adding a Feature Layer,” on page 55-11.) If you have GDB terrains that contain feature data, you can extract that data to shapefiles with the vectorNetworkToShape- Files utility. The syntax for the utility is as follows:
vectorNetworkToShapeFiles.exe terrain_file [output_directory]
where:
terrain_file is the GDB file to read.
output_directory is the directory in which to create the shapefiles. If output_directory is not specified then output files are named based on the name of the input file.
S-57 feature data does not have a spatial index, so it loads slowly. By contrast, shapefiles have a spatial index, so they load quickly. Therefore, we recommend that you convert S- 57 data to shapefiles. VR-Forces includes a command-line tool, ogr2ogr, that you can use to convert your S-57 data. (OGR is a sublibrary of GDAL, which VR-Forces uses to load feature data. Complete documentation is available at http://www.gdal.org/ogr/drv_s57.html and http://www.gdal.org/ogr2ogr.html.)
S-57 files have many layers of data. A shapefile only contains one layer of data. So, to convert your S-57 data, you must create a shapefile for each layer of data that you want to convert. Since VR-Forces does not use all of the data in an S-57 file, this is a simpler process than it might sound.
Before running ogr2ogr, set the following environment variables:
S57_CSV = <full_path_to>/appData/gdal_data
(The environment variable should specify a full path. If you use a relative path, it is rela- tive to the path from which you run ogr2ogr, not from the VR-Forces root. If you run ogr2ogr from ./appData/gdal_data, you do not have to set the variable.)
OGR_S57_OPTIONS = "RETURN_PRIMITIVES=ON,RETURN_LINK- AGES=ON,LNAM_REFS=ON"
This setting works for the layers that VR-Forces needs. If you want to convert other layers, you will have to research the proper environment variable settings.
Configuring Feature Data — Converting S-57 Feature Data to Shapefiles
The command syntax is:
ogr2ogr -skipfailures [-nlt type] output_file input_file layer
where:
-nlt type is the geometry type of the output layer. type can be NONE, GEOMETRY, POINT, LINESTRING, POLYGON, GEOMETRYCOLLEC- TION, MULTIPOINT, MULTIPOLYGON or MULTILINESTRING. Add "25D" to the end to make these 3D points.
input_file is the input data source (the S-57 file).
output_file is the name of the output file (the layer name with .shp at the end). All output files should be placed in the same directory. This simplifies configuring the earth file that references them.
layer is the name of the layer from the source to convert.
The following example commands convert the layers that VR-Forces needs:
ogr2ogr -skipfailures SOUNDG.shp S57FILE SOUNDG ogr2ogr -skipfailures -nlt POLYGON LNDARE.shp S57FILE
LNDARE
ogr2ogr -skipfailures DEPARE.shp S57FILE DEPARE ogr2ogr -skipfailures M_COVR.shp S57FILE M_COVR
There will be some output errors for each of these because they have some attributes that cannot be represented in shapefiles (like lists of numbers and strings).
Configuring Feature Data — Configuring Aggregate-Level Movement Restrictions
In aggregate-level scenarios, terrain features can affect movement of simulation objects. This is configured by the relationship of entries in featureconfig.txt and a simulation object’s movement system.
In featureconfig.txt, the terrain mobility configuration section specifies terrain restric- tion levels, as follows:
-- Terrain Mobility Configuration
--
MAK_UNRESTRICTED_TERRAIN: MAK_ROAD MAK_RESTRICTED_L1_TERRAIN: NONE
--MAK_RESTRICTED_L2_TERRAIN: mak_layer = "forest" MAK_RESTRICTED_L2_TERRAIN: NONE
--MAK_IMPASSABLE_TERRAIN: MAK_OBSTACLE MAK_IMPASSABLE_TERRAIN: NONE
MAK_INFANTRY_UNRESTRICTED_TERRAIN: MAK_UNRESTRICTED_TERRAIN MAK_INFANTRY_RESTRICTED_L1_TERRAIN: MAK_RESTRICTED_L1_TERRAIN MAK_INFANTRY_RESTRICTED_L2_TERRAIN: MAK_RESTRICTED_L2_TERRAIN MAK_INFANTRY_IMPASSABLE_TERRAIN: MAK_IMPASSABLE_TERRAIN
The restriction levels are referenced in the terrain-mobility block in a system definition file. The following code is from ground-aggregated-movement.sysdef:
(terrain-mobility (entry
(query-name "MAK_UNRESTRICTED_TERRAIN")
(speed-factor 1)
(priority 1)
)
(entry
(query-name "MAK_RESTRICTED_L1_TERRAIN") (speed-factor 0.75)
(priority 2)
)
(entry
(query-name "MAK_RESTRICTED_L2_TERRAIN") (speed-factor 0.4)
(priority 3)
)
(entry
(query-name "MAK_IMPASSABLE_TERRAIN") (speed factor 0)
(priority 4)
)
)
Configuring Feature Data — Dynamic Features
For example, in aggregate-level scenarios, users and simulation objects can create combat engineering objects (CEOs), such as minefields, fortified lines, and bridges, that can impede or facilitate unit movement. VR-Forces implements this capability by dynamically treating combat engineering objects as if they were terrain features.
VR-Forces maps entities to features in ./appData/settings/featureconfig.txt. The following is an example of some mappings:
-- Dynamic Features
--
MAK_ROUTE: {"1:17:0:0:2:-1:-1:-1"}
MAK_AREA: {"1:18:0:0:1:-1:-1:-1"}
MAK_DYNAMIC_OBSTACLE: {"1:18:0:0:2:-1:-1:-1"}
MAK_VRF_Roads: {"1:17:1:0:62:11:0:0"}
MAK_VRF_Bridges: {"1:17:1:0:62:12:0:0"}
MAK_VRF_Dynamic_Paths: (MAK_VRF_Roads OR MAK_VRF_Bridges) AND Percent_Complete >= *Minimum_Completion_Percentage_For_Effect
MAK_VRF_Engineering_Object_Points: {"1:16:1:-1:62:-1:-1:-1"}
MAK_VRF_Booby_Trap: {"1:16:1:0:62:1:0:0"}
MAK_VRF_Unexploded_Ordnance: {"1:16:1:0:62:2:0:0"}
MAK_VRF_Engineering_Object_Lines: {"1:17:1:-1:62:-1:-1:-1"}
MAK_VRF_Abatis: {"1:17:1:0:62:1:0:0"}
MAK_VRF_Anti_Tank_Ditch: {"1:17:1:0:62:2:0:0"}
MAK_VRF_Barbed_Wire: {"1:17:1:0:62:3:0:0"}
Although the individual procedures for managing terrain are fairly straightforward, understanding how they fit together to help you achieve your visualization goals is not always obvious. This chapter contains tutorials that demonstrate how to combine various procedures to create terrains and how to create a local terrain server.
Composing a Terrain through the GUI 63-2
Add Elevation Data (Add a Terrain Patch) 63-3
Creating a Terrain with an Earth File 63-14
Add Elevation Data to the Earth File 63-15
Add Imagery to the Earth File 63-15
Add Feature Data to the Earth File 63-16
Add Options to the Earth File 63-18
Load the Earth File and Save is as an MTF File 63-19
Extracting Props from a Terrain 63-20
Create a New Terrain and Add a Terrain Patch 63-21
Change the Model Definition for a Prop 63-23
This tutorial shows how to compose a terrain by combining elevation data, imagery, and feature data in the VR-Forces GUI. It recreates a portion of the LittlePond terrain that is included with VR-Forces. Little Pond is a small detailed area in a suburb of Boston, Massachusetts, U.S.A.
This tutorial shows you how to add props to the LittlePond elevation and image data. However, the tutorial does not ask you to add every type of prop that the complete LittlePond terrain contains. Therefore, at the completion of the tutorial, your terrain will not look exactly like the LittlePond terrain provided with VR-Forces. If you want to completely recreate the LittlePond terrain, you will have to continue to add props on your own.
The basic steps for composing a terrain are:
The first step in building a terrain is to add elevation data. Elevation data is added using terrain patches. The terrain patch in this tutorial is DTED data that covers about 1o east of Boston, Massachusetts, U.S.A.
To add the terrain patch:
If a scenario is open, close it.
Choose Observer Set Observer Mode Stealth.
Choose File New Terrain. This results in an empty window (Figure 63-1).
Choose Settings Terrain. The Terrain Settings dialog box opens.
Click Add Terrain Patch. The Add Terrain Patch dialog box opens and an Open dialog box opens on top of it.
In the Open dialog box, navigate to ./data/Terrain/LittlePond/elevation.
Select w072n042.dt1.
Click Open. Information about this terrain patch is displayed in the Add Terrain Patch dialog box (Figure 63-2).
Click OK. The terrain is added to the scene (Figure 63-3).
Figure 63-3. Terrain patch added
The terrain patch you added in the first step of this tutorial is just elevation data. It has no texture and no features. You can get some sense of its contours by enabling elevation coloring (Figure 63-4). However, this still does not provide the rich 3D environment you expect to see in a product like VR-Forces. Now we will add image data.
Figure 63-4. Elevation coloring
To add image data:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Raster Maps page (Figure 63-5).
Clear the Original Texture check box. (If you leave this selected, the terrain will be green.)
Click the Add button ( ) that is at the upper right of the list window (Figure 63-5). A line labeled Image 1 is added to the list in the window (Figure 63-6).
Click the Browse button at the right end of the image entry. The Image File dialog box opens.
In the Image File dialog box, navigate to ./data/Terrain/LittlePond/imagery.
Select W72N42.tif.
Add another image. This time, select LittlePond.tif.
Select the check box for the LittlePond.tif image (Figure 63-8). A high resolution image is added to the Little Pond Area of the terrain (Figure 63-9). (The high reso- lution image might be hard to find. The next section explains how to find it quickly.)
Figure 63-8. Raster Maps page with both images added
Figure 63-9. Little Pond image
It is not easy to find the Little Pond image unless you know where to look. To make things easier, we have saved an observer view of the Little Pond image. It will be the starting point for the rest of the tutorial.
To view the Little Pond image:
If the Observer Views Panel is not already displayed, choose View Observer Views Panel.
On the Observer Views Panel, click the Load View button ( ). The Load and Set Observers dialog box opens.
Select LittlePondTutorial.osrx.
Click Open. The view should jump to an image similar to Figure 63-9.
As an alternative to this procedure, you could hide the low resolution image by clearing its selection on the Raster Maps page. Then you could scroll through the terrain until you find the high resolution image.
The image of Little Pond shows lots of buildings and greenery, but these are just images, not 3D objects. Now we want to add props to the terrain. To do that, we need to add a feature layer that has objects that we can extract.
To add the feature layer:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Add Props page (Figure 63-10).
Click the Add button ( ) next to the Feature Layers list. The Select Source File for Feature Layer dialog box opens.
Navigate to ./data/Terrain/LittlePond/Features.
Select BuildingsP.shp.
Click Open. The layer is added to the Add Props page.
When you add a prop, VR-Forces extracts data from a feature layer and maps it to a model definition. You have to tell VR-Forces what to extract and what to map it to. You do this by building a rule.
To build a rule and extract feature data:
In the Terrain Settings dialog box, on the Add Props page, in the Build Rule group box, click the Add button ( ) (Figure 63-11). The Build Field/Value Pair dialog box opens.
In the Field list, select TYPE.
In the Value list, select HousesColonialGarrison (Figure 63-12).
Click OK.
On the Add Props page, in the Prop Type list, select the prop type for the rule. In this case, select Building.
In the Model Definition list, select HousesColonialGarrisonClapboardGreen.
In the Ground Clamp box, specify whether or not you want the prop to be ground- clamped.
In the Rotation list, select the orientation of your model. By default, if the GDB or Shapefile has a field called Rotation or DtOrientation, it is automatically selected. The completed rule is illustrated in Figure 63-13.
Click Execute Rule. The rule is executed. The Add Props page is updated (Figure 63-14) and houses are added to the terrain. Zoom in for a better look at them (Figure 63-15). (You might need to close the Terrain Settings dialog box or move it out of the way to see the terrain.)
Figure 63-14. Build rule implemented
Figure 63-15. Props added to terrain
If you want to, you can add more buildings by creating rules for some of the other building types available.
We will continue the tutorial by adding another feature type.
To add vegetation to the terrain:
If the Terrain Settings dialog box is not open, choose Settings Terrain.
Select the Add Props page.
Click the Add button ( ) next to the Feature Layers list. The Select Source File for Feature Layer dialog box opens.
Select ./data/Terrain/LittlePond/features/VegetationP.shp.
Click Open. A new feature layer is added to the list.
In the Build Rule group box, click the Add button ( ). The Build Field/Value Pair dialog box opens.
In the field list, select VEG.
In the Value list, select TreesBigLeafMaple.
Click OK.
In the Prop Type list, select Tree.
In the Model Definition list, select TreesBigLeafMapleST. The build rule should look like Figure 63-16.
Click Execute Rule. The page is updated and trees are added to the terrain (Figure 63-17).
Save the terrain.
You can build additional rules to add other types of vegetation to the terrain. When you are done, you can create another feature layer with the architecture shapefile (Infrastruc- tureP.shp) and add light posts, fire hydrants, and street signs to the terrain.
In “Composing a Terrain through the GUI,” on page 63-2, we showed you how to compose a terrain by adding various terrain components in the VR-Forces GUI and saving the resulting terrain as an MTF file. Another way to load terrain into VR-Forces is by using a terrain server. Terrain servers are configured in earth files, which are XML files using osgEarth syntax. All the information that VR-Forces needs to load elevation, imagery, and feature data is provided. The data can be stored locally or elsewhere on a network or the internet. Data is streamed over the network and paged in as needed.
In this tutorial we use the same local data we used for the Little Pond terrain in the previous tutorial, except that instead of adding the data through the GUI, we create an earth file to load it.
VR-Forces comes with a terrain Little Pond (online).earth that merges the local Little Pond data with streaming terrain from VR-TheWorld Server. For this tutorial we will ignore the rest of the world and focus on Little Pond.
One approach to creating an earth file is to start with one of the earth files provided with VR-Forces, keep the basic structure, and add, edit, or replace elements as needed. For this tutorial, we will start from an empty file and build all the major elements.
The root element in an earth file is the map element. It encloses all other elements. Open a text editor and add the following code:
<map name="Little Pond" type="geocentric" version="2">
</map>
Elevation data is configured using an elevation element. We want to specify the same elevation data here that we did in the previous Little Pond tutorial. Add the following text after the opening of the map element:
<elevation name="Little Pond Elevation" driver = "gdal">
<url>../../data/Terrain/LittlePond/Elevation/w072n042.dt1</url>
<tile_size>32</tile_size>
</elevation>
The location of data in an earth file is provided in a url element. We need to use the gdal driver to load elevation data.
Image data is configured using image elements. Add the following text after the
elevation block:
<image driver="composite">
<image name="Little Pond Imagery" driver="gdal">
<url>../../data/Terrain/LittlePond/Imagery/W72N42.tif</url>
</image>
<image name="Little Pond Imagery" driver="gdal">
<url>../../data/Terrain/LittlePond/Imagery/LittlePond.tif</url>
</image>
</image>
The Little Pond terrain has two image files, a large low-resolution image and a smaller higher resolution image. If we were to simply add two image elements to the earth file, only the last one listed would be loaded. We would only see one of the images.
To use more than one image, we place an image element for each image file inside an image element that uses a composite driver. List the images from bottommost to topmost. If you list them in the opposite order from the code, LittlePond.tif would be underneath W72N42.tif and you would not be able to see it.
We use the gdal driver to load the images.
In earth files, you add feature data, such as buildings and vegetation, using a model element. You can add as many model elements as you need. A model element specifies the location of a shapefile. Then it adds style elements for each feature type to add from the shapefile. In the previous Little Pond tutorial, we added feature layers using BuildingsP.shp and VegetationP.shp. Then we added one kind of building (green colonial garrison house) and one kind of plant (big leaf maple tree). In this tutorial we will add one kind of house and all of the vegetation in the shapefile.
Add the following code to your earth file after the image block:
<model name="Little Pond Buildings" driver="feature_geom">
<features name="Buildings" driver="ogr">
<url>../../data/Terrain/LittlePond/Features/BuildingsP.shp</url>
</features>
<layout>
<tile_size_factor>3</tile_size_factor>
</layout>
<styles>
<style type="text/css"> HousesColonialGarrison { model:
"../../data/Structures/HousesColonialGarrisonClapboardGreen.medf"; model-heading: 0-[rotation];
model-scale: 1; model-placement: vertex;
altitude-clamping: terrain;
altitude-resolution: 0.00008583068847656250;
altitude-offset: 0;
}
</style>
<selector class="HousesColonialGarrison">
<query>
<expr>TYPE = 'HousesColonialGarrison'</expr>
</query>
</selector>
</styles>
<clustering>false</clustering>
<lighting>true</lighting>
</model>
As in the other elements, the url element specifies the location of the shapefile. To load buildings, you need to use the feature_geom driver for the model element and the ogr driver for the features element.
The styles element lets you specify a style for each building you want to display. This example shows just one building. Take a look at Little Pond (online).earth to see the other buildings that can be configured from this shapefile.
Each style has a name, in this case HousesColonialGarrison. The model attribute spec- ifies the model used to display the object. The selector element matches the style to an entry in the TYPE column in the database file that accompanies the shapefile (Build- ingsP.dbf).
To better understand this relationship, open BuildingsP.dbf in a spreadsheet application (Figure 63-18). Remember that in the first Little Pond tutorial, you built a rule for extracting props from the feature layer. You chose TYPE in the field list. That is because the TYPE column lists the different types of buildings in the shapefile. You do the same thing with the selector element.
Figure 63-18. BuildingsP.shp
To add vegetation to the terrain, add the following code to the earth file after the
model block for the buildings:
<model name="Little Pond Vegetation" driver="feature_custom">
<features name="Vegetation" driver="ogr">
<url>../../data/Terrain/LittlePond/Features/VegetationP.shp</url>
</features>
<layout>
<tile_size_factor>3</tile_size_factor>
</layout>
<styles>
<style type="text/css"> Vegetation {
marker: [veg] + "ST" ;
marker-scale: 1; marker-placement: vertex; altitude-clamping: terrain;
altitude-resolution: 0.00008583068847656250;
altitude-offset: 0;
}
style>
</styles>
<clustering>true</clustering>
<lighting>true</lighting>
</model>
The vegetation in VR-Forces uses SpeedTree models. To load SpeedTrees from an earth file, you need to use the feature_custom driver in the model element. You use the ogr driver in the features element. Similar to the buildings, the model block for vegeta- tion specifies a shapefile and styles. However, unlike with the buildings, we do not specify individual models to load. The marker attribute indicates that VR-Forces should take every entry in the VEG column of VegetationP.shp, append ST to it, and look for a model of that name. For example, the column has several entries named TreesBigLeafMaple. VR-Forces adds ST to form TreesBigLeafMapleST, finds the model definition TreesBigLeafMapleST, and loads the model specified in the model definition.
Finally, add some common options to the file. In particular, this section specifies a loca- tion for the cache. Add this block just before the closing of the map element:
<options>
<lighting>true</lighting>
<elevation_interpolation>triangulate</elevation_interpolation>
<terrain>
<min_tile_range_factor>3</min_tile_range_factor>
<skirt_ratio>0.1</skirt_ratio>
</terrain>
<cache type="filesystem">
<path>../../appData/cache</path>
</cache>
</options>
The convention for saving earth files is to save them in the ./userData/servers directory. Save the file as myLittlePond.earth.
Your earth file for Little Pond is complete. Now you can load it in VR-Forces and compare it to the terrain you created through the GUI. After you load it, you should save it as an MTF file.
To load the earth file:
Start VR-Forces.
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Terrain Contents page.
Click Add Terrain Server. The Add Terrain Server dialog box opens.
In the Servers list, select myLittlePond.earth.
Click Connect. The terrain loads. It is visible as a small patch on the earth’s sphere (Figure 63-19).
Zoom in on the terrain (Figure 63-20). Compare it to the terrain you created in the first Little Pond tutorial. Notice that the buildings are the same, but there are more types of vegetation.
Choose File Save Terrain. The Save Terrain dialog box opens.
Give the terrain a name. Do not use Little Pond unless you want to overwrite the Little Pond terrain provided with VR-Forces.
In the tutorial “Composing a Terrain through the GUI,” on page 63-2, we extract props from a feature layer by building a rule in the Add Props page. In this tutorial, we demonstrate the other way to create a prop – by extracting information from a terrain.
The general steps for extracting props from a terrain are:
Create a new terrain with a terrain patch (“Create a New Terrain and Add a Terrain Patch,” on page 63-21).
Select the external references that you want to extract as props and extract them (“Extract the Props,” on page 63-21).
Optionally, change the model definitions (“Change the Model Definition for a Prop,” on page 63-23).
To create the new terrain and add a terrain database:
Choose File New Terrain. If any terrain data is loaded, it is removed.
Choose Settings Terrain. The Terrain Settings dialog box opens.
Click Add Terrain Patch. The Add Terrain Patch dialog box opens.
Navigate to the ./data/Terrain/Makland/Geometry/OpenFlight directory.
Select Makland.flt.
In the Add Terrain Patch dialog box, click OK. The terrain is loaded.
To extract the props:
Move the observer so that you have a view of the plateau in Makland similar to Figure 63-21.
Click on the trees or buildings in the scene. Notice that you cannot select them. They are part of the terrain; they do not exist as props.
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Extract Props page (Figure 63-22). On the Extract References tab, the External References window lists all of the objects in the terrain that are incorpo- rated into the terrain by reference. These are the objects that you can extract as props. You can extract them individually. For this tutorial, we will extract all of them.
Click Select All. All of the references are selected.
In the Extract To group box, click Extract Selected. The objects are extracted as props. The list of external references is cleared.
Click the trees and buildings on the plateau. You can now select them because they are props, not part of the terrain (Figure 63-23). They are displayed using the geometry in the OpenFlight files from which they were referenced. You can change the models that the props use if you want to. For example, you might want to change the trees to SpeedTrees.
To change the model definition for a prop:
Select one of the trees.
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the Edit Existing Props page. The selected prop is highlighted in the list of props (Figure 63-24).
In the Model Definition box, select a model definition from the list, such as Trees- GiantRedwoodST. The tree changes to the new model definition (Figure 63-25).
To restore the tree to its original model, on the Edit Existing Props page, change the model definition to Use Extracted Geometry.
Creating and Editing Simulation Models
This section explains how to use the Simulation Object Editor and OPD Editor to create and edit simulation model sets and the simulation models used by simulation objects. It also covers configuration files that you must edit by hand.
Section XI - Creating and Editing Simulation Models VR-Forces Users Guide
XI-1
Section XI - Creating and Editing Simulation Models
XI-2 VT MAK
64. The Simulation Object Editor and SMSs
Introduction to the Simulation Object Editor 64-3
Starting the Simulation Object Editor 64-4
Including Simulation Model Sets in other Simulation Model Sets 64-6
SMS Priority for Included and Multiple SMSs 64-8
Lua Scripts in Included SMSs 64-9
Application Level Files in Included SMSs 64-9
Search Paths for Referenced Files in an SMS 64-10
Promoting a Model to the Loaded SMS 64-11
Visual Model Definitions 64-12
User-Created Visual Definition Files 64-12
Migrating an SMS to a New Release 64-13
Upgrading Old Simulation Model Sets 64-14
Opening a Simulation Model Set 64-16
Creating a New Simulation Model Set 64-17
Creating a Completely New Simulation Model Set 64-18
Specifying the Default Simulation Model Set for Scenarios 64-18
Applying Platform Updates 64-19
Editing the Category List 64-19
The Simulation Object Editor and SMSs
Undoing Category Changes 64-21
Managing the Forces List 64-22
The Simulation Object Editor and SMSs — Introduction to the Simulation Object Editor
The Simulation Object Editor lets you create and edit simulation model sets and the objects in them.
Many VR-Forces users want to edit some or all of the following simulation object char- acteristics:
Weapon systems.
Basic parameters.
Sensors.
2D icons and 3D models.
Formations.
Users also want to add new simulation objects or tactical graphics types. The Simula- tion Object Editor allows you to edit most of the aspects of a simulation object or tactical graphic that a typical VR-Forces user will want to change. You can easily add and remove sensors, weapon systems, and other major component systems, change the 2D and 3D models used to represent them, and edit their properties.
The Simulation Object Editor primarily lets you edit properties that affect simulation. Simulation objects also have visualization models, which are configured in the front-end in the Visual Model Editors and Simulation Object Type Mappings dialog boxes. However, the Simulation Object Editor also lets you configure the 3D models and 2D icons used to display simulation objects. For more information, please see Chapter 82, Mapping Models and Effects and Chapter 81, Model and Element Definitions.
The Simulation Object Editor does not let you add or remove individual components or edit most of the more detailed entity parameters. For these advanced editing tasks, you can use the OPD Editor, which is described in Chapter 70, Using the OPD Editor, or edit specific configuration files, which are described throughout this manual.
If you want to add new simulation objects or customize the simulation objects supplied with VR-Forces, start with the Simulation Object Editor. Use the OPD Editor or a text editor only if the Simulation Object Editor does not let you make the changes you need to make.
The Simulation Object Editor and SMSs — Starting the Simulation Object Editor
To start the Simulation Object Editor in Windows, choose MÄK Technologies VR-Forces 4.5 Tools Simulation Object Editor. The Simulation Object Editor opens (Figure 64-1).
Figure 64-1. Simulation Object Editor
To start the Simulation Object Editor from the command-line in Windows or Linux:
Change directory to ./bin64.
Run:
simulationObjectEditor options
Table 64-1 describes the command-line arguments for the Simulation Object Editor.
Table 64-1: Simulation Object Editor command-line arguments
(-- | --ignore_rest) Ignores the rest of the labeled arguments following
this flag.
--appDataDir directory Specifies the location of application data.
--dataDir directory Specifies the location of the data directory (terrains
and so on).
--doNotCheckPluginVersions Do not check versions in the plug-ins to make sure
they can load against this version of the application.
--doNotLoadVrfPlugins Do not load the plug-ins contained in XML files in the
./plug-ins directory.
Table 64-1: Simulation Object Editor command-line arguments
(-G | --locale) language The name of the language to load into the GUI.
(-h | --help) Displays usage information and exits.
--launcherLocation
location
--layoutSettingsFile
filename
Specifies the location of the VR-Forces launcher.
Specifies the GUI layout settings file to use. filename specifies the base filename. It is prefixed with default_ and the extension .uisx is added. Default: SOEUILayoutSettings.
--loadPlugin filename Load the specified Simulation Object Editor plugin.
Can be a specific plug-in or plug-in XML file.
--opdEditorLocation string Location of the OPD Editor application.
--settingsDirectory string Sets the directory to load all ui and settings files
from.
--showConsole Show the console.
--smsFile string Loads the specified SMS file.
(-v | --version) Displays version information and exits.
--visualTerrain string Terrain used when displaying simulation objects.
A simulation model set (SMS) defines all of the simulation objects, tactical graphics, and other object models that you can create in a VR-Forces simulation. The simulation model set file tells VR-Forces where to find all of the configuration files it needs to create, simulate, and display simulation objects and other objects. Every scenario must reference one or more simulation model sets.
VR-Forces provides the following SMSs:
base.sms. Defines platforms and graphics used by other SMSs.
EntityLevel.sms. Defines entities, units, and other objects used for entity-level scenarios. Includes base.sms.
AggregateLevel.sms. Defines units and other objects used for aggregate-level scenarios. Includes base.sms.
For details about entity-level modeling and aggregate-level modeling, please see “Entity-Level Modeling and Aggregate-Level Modeling,” on page 15-10.
!
!
When you use the Simulation Object Editor, you are editing a simulation model set. We recommend that you keep the default SMSs as reference model sets and not edit them. If you want to edit entity models, create a new SMS based on one of the provided SMSs and use it as the default SMS for your scenarios. For details about creating a new SMS and changing the default SMS, please see “Creating a New Simulation Model Set,” on
page 64-17.
VR-Forces simulation model sets can include other SMSs. This allows you to create core SMSs that can be included in multiple other SMSs that may have incompatible characteristics or which override some characteristics of the core SMS, but which still need core objects.
VR-Forces provides three SMSs, base.sms, EntityLevel.sms, and AggregateLevel.sms. Enti- tyLevel.sms and AggregateLevel.sms both include base.sms, which has platform files and graphics that they both need.
It is important to understand the difference between using an SMS that includes other SMSs and creating a scenario that uses multiple SMSs. Since VR-Forces users usually create new SMSs to configure new types of simulation objects, or add new systems to existing objects, we will consider the differences in that context.
If you want to create a custom stand-alone SMS for a new or enhanced object, that SMS must include all of the files required to support that object, such as an OPE file, entity file, system files, damage files, and so on. When trying to build such an SMS, it can be easy to overlook required files. This process also requires you to duplicate files that are contained in the supplied SMSs even if you do not need to change them, because the SMS must contain all the files it needs. Then, if you do not load the SMSs in the correct order, your customization can be overridden by one of the other SMSs you are using in the scenario. In summary, it is a cumbersome process that can create needless duplication of files and be difficult to debug if problems arise.
Using included SMSs minimizes the problems inherent in using multiple stand-alone SMSs. When an SMS includes another SMS, it has a higher priority than the included SMS. When an SMS is loaded, included SMSs are loaded first, and each subsequent SMS has a higher priority than the previously loaded SMS. Any parameters or files in the higher priority SMSs that are also in the lower priority SMSs override those in the lower priority SMSs. The higher priority SMSs do not need to contain any files that they do not change from the included SMSs. Therefore the total footprint of the SMS is smaller.
To include an SMS in another SMS:
Choose MÄK Technologies VR-Forces 4.5 Tools Simulation Object Editor. The Simulation Object Editor opens (Figure 64-1).
Choose File Open Simulation Model Set. The Open Model Set dialog box opens.
Select the parent SMS.
Click Open. The SMS is loaded.
Choose Edit Included Simulation Model Sets. The Edit Included Simulation Model Sets dialog box opens.
Figure 64-2. Edit Included Simulation Model Sets dialog box
Click the Add button ( ). A line is added to the window with the text <empty file>.
Click the Browse button at the end of the line. The Choose File dialog box opens.
Select the SMS that you want to include.
Click Open. The SMS is added to the list in the window.
Click OK. The SMS is saved and reloaded.
When you load multiple SMSs either through inclusion or by specifying multiple SMSs for a scenario, conflicts are resolved through the priorities of the SMSs.
For included SMSs, priority is based on the inclusion relationships. The highest level SMS is loaded last and has the highest priority. Simulation objects in higher priority SMSs override those in lower priority SMSs. For example, suppose you create a new SMS called mySMS that includes EntityLevel.sms. EntityLevel.sms already includes base.sms. When VR-Forces loads mySMS it loads base.sms first. Then it loads Enti- tyLevel.sms, and finally mySMS. Objects in mySMS override objects in EntityLevel.sms that have the same object type, which in turn overrides base.sms.
When you load multiple SMSs, priority is based on the order in which they are loaded. Assuming a simple case of two SMSs that do not include other SMSs, if the second SMS loaded specifies objects that are also in the first SMS loaded, the specification in the second SMS takes precedence.
mySMS.sms
EntityLevel.sms
base.sms
yourSMS.sms
EntityLevel.sms
base.sms
If mySMS.sms is the first SMS loaded, VR-Forces loads base.sms, then EntityLevel.sms, then mySMS.sms. Priority is determined as described previously for an SMS with included SMSs. Then VR-Forces loads yourSMS.sms. It starts with base.sms. Since base.sms is already loaded, VR-Forces ignores it. Then it moves to EntityLevel.sms. Since EntityLevel.sms is already loaded, it ignores it. Then it loads yourSMS.sms. If yourSMS.sms has objects that conflict with mySMS.sms, then yourSMS.sms overrides them.
The overall priority for the SMSs in this example, from lowest to highest, is base.sms, EntityLevel.sms, mySMS.sms, yourSMS.sms.
The priority of multiple SMSs is determined by the order in which they are listed in the Simulation-Model-Set-Files parameter in the scenario file. In the following example, Enti- tyLevel.sms has the highest priority. When you create a scenario and list multiple SMSs, the priority in the SMS list is top to bottom.
(Simulation-Model-Set-Files "..\data\simulationModelSets\EntityLevel.sms" "..\data\simulationModelSets\developer_toolkit_examples\addTask.sms")
System scripts are stored in simulation model sets. When you load an SMS that includes another SMS, the scripts in the highest priority SMS supersede those in the lower priority SMSs.
The highest priority scripts get used by all simulation objects, regardless of which SMS they are in. For example, suppose EntityLevel.sms has a script called Patrol Area and mySMS.sms (the higher priority SMS) also has a script called Patrol Area. If the entity M1A2, which is defined in EntityLevel.sms executes the Patrol Area task, it will use the version in mySMS.sms.
Lua scripts in included SMSs have the following additional relationships:
Any scenario scripted task promoted to a system scripted task is promoted into the highest-priority SMS.
If you edit a scripted task that is in an included SMS, it is saved into the highest- priority SMS. The version of the script in the included SMS does not change. Therefore if you want a change to a script to affect all uses of that script, edit it in its own SMS.
Application-level SMS files, such as commModelParams.mtl or gui/initialCreateMenuCo- nfiguration.xml, are included the same way entity-specific files are and you do not need to have copies of them in a parent SMS as long as one of the child SMSs has them.
However every SMS must have vrfSim.opd.
The simulation objects in a scenario reference many files to determine their behavior, such as system definition files, damage tables, ammunition selection tables and so on. If all the simulation objects in a scenario are configured in one SMS, then all of the refer- enced files are within the file hierarchy of that SMS. However, if you use an SMS that includes other SMSs, then simulation objects may have to search within multiple SMSs to reference the correct files.
An SMS can load files from any SMS it includes, and any currently loaded SMS it is included in.
File referencing, as with other aspects of included SMSs, is based on the priority of the SMS in which an object is configured. Given the SMSs in Figure 64-3, the search paths for each SMS, from lowest to highest priority would be:
base.sms. Can search in base.sms, EntityLevel.sms, mySMS.sms, and yourSMS.sms.
EntityLevel.sms. Can search in base.sms, EntityLevel.sms, mySMS.sms, and
yourSMS.sms.
mySMS.sms. Can search in base.sms, EntityLevel.sms, and mySMS.sms.
yourSMS.sms. Can search in base.sms, EntityLevel.sms, and yourSMS.sms.
When you load an SMS that has included other SMSs, the objects from the included SMSs are listed, but you cannot edit them. You can only edit them by editing the SMS to which they belong. Figure 64-4 shows the Space category for addEntity.sms. (It is in the developer toolkit examples for the addEntity example.) The Space Shuttle entity that is part of the parent SMS is editable, but the two entities included from Enti- tyLevel.sms are not. Note in the figure that most of the parameters for the Space Shuttle in EntityLevel.sms are read-only.
Since one of the purposes of being able to include SMSs in the loaded SMS is to customize simulation objects in the included SMSs, you can promote objects from the included SMS to the loaded SMS. The object then becomes editable and is saved in the loaded SMS. When the SMS is loaded, the object in the loaded SMS overrides the object in the included SMS.
To promote an object to the parent SMS:
Load the parent SMS.
Select the object you want to promote.
Choose Model Promote to Main Simulation Model Set. The object is added to the parent SMS and is now fully editable. When you save the SMS, a new .entity file is added to it.
The Simulation Object Editor and SMSs — Visual Model Definitions
VR-Forces stores visual model definitions in different places depending on which SMS is loaded, as follows:
When the Simulation Object Editor loads base.sms, EntityLevel.sms, or Aggre- gateLevel.sms, it reads the appropriate definition files for the SMS from the directo- ries under ./appData/definitions. When you save changes to one of these SMSs, the changes are written back to the original definition files.
If you create a new SMS, model and element definition files get saved with the SMS in the ./data/simulationModelSets/<sms>/gui/visuals directory for the new SMS. When you load the SMS, it reads model and element definitions from the SMS- specific files.
For information about model and element definition files, please see Chapter 81, Model and Element Definitions.
Although we recommend that you use the Simulation Object Editor for all changes to visual models, it is possible to add new model definitions and element definitions using the Visual Model Editors dialog box, instead of the Simulation Object Editor. Addi- tionally, some attributes of element definitions cannot be set in the Simulation Object Editor, so if you want to change them, you have to use the Visual Model Editors.
The new and changed definitions can be exported to files other than the default set of definition files. In fact, in many cases, we recommend that you export them to their own files. However, creating new model or element definitions in the Visual Model Editors and saving them to new files has implications for how they are loaded and saved by the Simulation Object Editor.
When the Simulation Object Editor loads one of the three default SMSs, it loads all files in the appropriate directories, including any additional files that you have created. However, when VR-Forces saves changes to the SMS, it writes the changes only to the default definition files for the SMS. It does not write back to the user-created definition files. Since the user-created files are still in the directory, the next time you load the SMS, there may be conflicts between the files and the results may be unexpected.
Given this behavior, the recommended work flow for reconciling new definitions created in the Visual Model Editors dialog box is as follows:
In the Visual Model Editors dialog box, save new model or element definitions to new files in the default definition directories.
Open the affected SMS in the Simulation Object Editor.
Confirm that your new model or element definitions have been loaded by the SMS.
Save the SMS. This saves the new definitions into the default set of SMS definition files.
Delete the individual definition files that you created in step 1 so that there are no conflicts with the SMS.
If you create a new SMS, when the Simulation Object Editor loads the SMS, it only loads the definition files that it previously created. If you create additional leaf or model definition files with the Visual Model Editors dialog box, they do not get loaded. You must import them into your SMS. Therefore the recommended work flow is as follows:
Open a scenario that uses your SMS.
In the Visual Model Editors dialog box, load the .hier file for your SMS. It is either
./appData/definitions/Aggregate/ElementDefinitions/coreAggregateElementDefini- tions.hier or ./appData/definitions/Entity/ElementDefinitions/coreEntityElementDefi- nitions.hier.
Import the model definition or element definition file to which you want to add new definitions. Be sure to import it from the files in the /gui/visuals directory for your SMS. Be sure that you only edit one element definition file at a time.
Add new definitions as desired.
Export the new definitions to the definition file that you imported.
Open the SMS in the Simulation Object Editor and confirm that the new defini- tions are available.
When you edit an SMS in the Simulation Object Editor, it:
Creates or edits .entity files for the simulation objects that you edit.
Modifies visual definition files and entity type mappings.
The Simulation Object Editor does not create or change any other files. It is possible that you may add or edit some of the files that entity systems reference, such as damage files. You might also create or modify scripts that are stored in an SMS.
If you upgrade to a new version of VR-Forces, you can quickly add any of the new simulation objects you created by copying their .entity files into an SMS in the new release. This will make the simulation objects available to the simulation engine, but will not include their visual definitions. For each entity that you add this way, you will have to edit the 2D and 3D models in the Simulation Object Editor.
If you made any changes to other files, you may have to copy those changed files to the new SMS.
If you have written scripts, use the script export process to export them from the previous release of VR-Forces and then import them into the new release.
The Simulation Object Editor and SMSs — Migrating an SMS to a New Release
Over time, the SMS format has changed. The Simulation Object Editor has a process for upgrading older SMSs. For details, please see “Upgrading Old Simulation Model Sets,” on page 64-14.
The SMS organization changed considerably from VR-Forces 4.1.x to 4.2. At that time, SMSs started using .entity files to configure individual simulation objects. In VR- Forces 4.3, the ability to include SMSs in other SMSs was added. The SMS upgrade tool helps you migrate SMSs through these different transitions.
If you need to migrate a pre-VR-Forces 4.2 SMS, the upgrade tool converts your old SMS into the XML file format used for VR-Forces 4.2 and later. If you upgrade an SMS from VR-Forces 4.2 to 4.3 or later, it takes into account the transition from the default.sms to EntityLevel.sms, which includes base.sms.
When you upgrade a 4.2 or later SMS, you create a completely new SMS. The upgrade tool:
Copies all files except .entity and simulation object group (.sog) files from a current SMS (that is, an SMS from the latest version of VR-Forces) into the new SMS. (Optionally, you can copy all .entity and .sog files to the new SMS. The tool does not copy all .entity files by default because users often create SMSs with new simu- lation objects or a small subset of the simulation objects in the SMSs provided with VR-Forces. The default behavior is to create a new SMS that only has the simula- tion objects in the SMS being upgraded.)
Copies all of the files from the old SMS, including .entity files, but not .opd or .mst files, into the new SMS, if necessary. (Files that are part of an included SMS are not copied.) If .entity files in the old SMS match the names of files in the current SMS, the old files overwrite the current files.
If the following file types with the same name have different content, the tool warns you about these differences. You must reconcile them manually.
xml
lua
sysdef
mtl
tsk
ui.
To upgrade an old SMS:
Open the Simulation Object Editor.
Choose File Upgrade Old Simulation Model Set. The Select SMS to Upgrade dialog box opens (Figure 64-5).
Select the SMS you want to upgrade.
Specify a name for the new SMS.
Specify the SMS you want to base the new SMS on – EntityLevel.sms or Aggre- gateLevel.sms.
Optionally, select Copy Entity Files from Current SMS.
Click Finish. The upgrade tool runs.
The Simulation Object Editor and SMSs — Opening a Simulation Model Set
To open a simulation model set:
Choose File Open Simulation Model Set. The Open Model Set dialog box opens.
Select the SMS you want to open.
Click Open. The SMS is loaded and a list of simulation objects is displayed in the Simulation Object Editor.
Entity list
Figure 64-6. Simulation Object Editor with simulation model set loaded
The Simulation Object Editor and SMSs — Creating a New Simulation Model Set
You can create new SMSs by copying and editing an existing SMS or you can create a completely new SMS and create the simulation objects that you want to include in it. When you create a new SMS, you can specify that it include other SMSs.
To create a new simulation model set from an existing SMS:
Choose File New Simulation Model Set. The New Simulation Model Set dialog box opens (Figure 64-7).
Select Create From Existing Simulation Model Set.
Click Next. The Select Model Set to Copy dialog box opens.
Select a model set and click Next. The Include Simulation Model Sets dialog box opens. It lists the SMSs included in the SMS that you are copying.
Optionally, edit the list of SMSs to be included. (For details about how to add and remove included SMSs, please see the procedure in “Including Simulation Model Sets in other Simulation Model Sets,” on page 64-6, starting with step 6.)
Click Next. The New Model Set Name dialog box opens.
In the File name box, type a name for the new model set.
Click Finish. The Simulation Object Editor loads information from the source model set.
Make any changes you want to the model set.
Choose File Save Simulation Model Set.
The Simulation Object Editor and SMSs — Importing .entity Files
To create a completely new simulation model set:
Choose File New Simulation Model Set. The New Simulation Model Set dialog box opens (Figure 64-7).
Select Create New Simulation Model Set.
Click Next. The New Model Set Name dialog box opens.
In the File name box, type a name for the new model set.
Click Finish. The Simulation Object Editor loads systems information from the default model set.
Create the simulation objects that you want to have in the model set, as described in “Creating a New Simulation Object,” on page 65-32.
Choose File Save Simulation Model Set.
When you create a new scenario, the New Scenario dialog box lists EntityLevel.sms as the SMS to use. You can change the default SMS. For details, please see “Specifying the Default SMS Configuration,” on page 7-11.
If you have .entity files that you created with a previous version of VR-Forces or by multiple persons on different computers, you may want to import them into an SMS. The easiest way to do this is to copy the files into the vrfSim directory in the SMS (./data/simulationModelSet[<model_set>/vrfSim). However, you can also import the files from the Simulation Object Editor.
To import .entity files into an SMS:
Choose File Add Entity File. The Add Entity File dialog box opens.
Select the file that you want to import.
Click Open. The file gets copied to the SMS.
All simulation object models reference one of the basic platforms, such as ground, fixed-wing, and point object. Most simulation objects reference one or more system definition files. If you update the variable bindings in a platform file or system defini- tion file, you must apply these changes to the simulation objects of that platform type. Although you could do this by hand, as described in “Adding Variable Bindings to Plat- form and System Files,” on page 69-21, that would be a tedious and error-prone activity. The Simulation Object Editor can apply all updates to all files automatically.
To apply platform updates:
Choose File Apply Platform Updates. An information prompt opens.
Click OK.
If you want to organize simulation objects into categories that are not included in the default category list, you can add new categories. You can also remove and rename cate- gories.
The procedures in this section also apply to editing the Used By Countries list. Select Used by Countries on the Edit menu instead of Categories.
The Simulation Object Editor and SMSs — Editing the Category List
To add a new category:
Choose Edit Categories. The Categories Editor opens (Figure 64-8).
Click Add. The New Category dialog box opens.
Type the name of the new category.
Click OK. The new category is added to the list in the Categories Editor.
Click OK.
If you add a category and do not assign a simulation object to it, it does not get saved when you save the simulation model set.
To remove a category:
Choose Edit Categories. The Categories Editor opens.
Select the category that you want to remove.
Click Remove.
Click OK.
To rename a category:
Choose Edit Categories. The Categories Editor opens.
Select the category that you want to rename.
Click Rename. The Rename dialog box opens.
Type the new name.
Click OK. The categories list is updated.
Click OK.
You can undo changes made to the category list and entity category assignments.
!
!
When you undo category changes, all changes to the categories list and all changes to entity category assignments made since the last save of the simulation model set are reversed. Be sure that this is what you want before completing this procedure.
To undo category changes:
Choose Edit Revert Categories. A confirmation prompt is displayed.
Click Yes.
Adding new forces may be useful if you are simulating participants from multiple coun- tries or if you want to easily model and change force relationships for non-govern- mental forces such as militias or insurgent groups.
To add a force:
Choose Edit Forces. The Forces Editor opens (Figure 64-9).
Click Add. The Force Hostility Editor opens (Figure 64-10). The new force is assigned a force ID. You cannot edit the force ID.
In the Force Name box, type a name for the force.
Click the Color button. A color picker opens.
The Simulation Object Editor and SMSs — Managing the Forces List
Select a color for the force.
Optionally, in the Hostile Against window, select the forces that the new force will be hostile towards. (You can change hostility at run time in the Hostility Matrix. For details, please see “Managing Force Hostility Relationships,” on page 9-10.
If you want the force to be listed in dialog boxes that list forces, select the Include in Dialogs check box.
Click OK.
Click Close.
You can edit a force’s name, color, hostility, and use. Each force has a force number. When you edit a force, you are changing the attributes of that numbered force.
To edit a force:
Choose Edit Forces. The Forces Editor opens (Figure 64-9).
Select the force that you want to edit.
Click Edit. The Force Hostility Editor opens (Figure 64-10).
To edit the name, change the text in the Force Name box.
To edit the color associated with the force, click the Color button and choose a color from the color picker.
To edit hostility relationships, in the Hostile Against window, select the forces that the force should be hostile towards.
To edit whether or not the force is listed in dialog boxes that list forces, select or clear the Include in Dialogs check box.
Click OK.
Click Close.
To remove a force:
Choose Edit Forces. The Forces Editor opens (Figure 64-9).
Select the force that you want to remove.
Click Remove. The force is removed from the list.
Click Close.
65. Editing Simulation Object Models
This chapter explains how to use the Simulation Object Editor to edit individual objects in EntityLevel.sms. Many of the concepts and procedures also apply to units. For details about editing units, please see Chapter 66, Editing Units for Entity-Level Scenarios and Chapter 67, Editing Aggregate-Level Objects.
Editing Generic Object Parameters 65-3
Selecting an Object to Edit 65-3
Editing an Object’s Categories 65-3
Changing an Object’s Object Type Enumeration 65-4
Changing an Object’s Name 65-7
Specifying Whether an Object Can Be Created 65-7
Specifying the Object Creation Palette 65-7
Specifying the Default Overlay 65-8
Undoing (Reverting) Changes to an Object 65-8
Editing Parameters that are Specific to Simulation Objects 65-9
Editing a Simulation Object’s Used By Countries List 65-9
Editing a Simulation Object’s Bounding Volume (Size) 65-10
Displaying a Simulation Object’s Bounding Volume 65-11
Specifying Support Points 65-12
Excluding Entities from Batch Bounding Volume and Support Point Updates 65-12
Editing Behavioral Parameters 65-12
Adding Object Geometry to an Entity 65-14
Ground Clamping Cultural Features 65-15
Editing a Lifeform’s Visual Model and Animation 65-16
Editing a Simulation Object’s Visual Model 65-19
Editing Simulation Object Models
Changing the 3D Model or Colorized Model 65-20
Changing the 2D Icon Using a Font 65-21
Changing the 2D Icon Using an Image 65-21
Editing a Spot Report Icon 65-23
Adding a New Visual Model or Image 65-24
Displaying Details about the Visual Model 65-25
Reloading Visual Models in the VR-Forces GUI 65-27
Editing a Simulation Object’s Systems 65-28
Selecting a Damage Model 65-30
Selecting a Movement Model 65-30
Editing a System’s Properties 65-31
Editing a System in the OPD Editor 65-31
Creating a New Simulation Object 65-32
Creating a New Model from an Existing Model 65-33
Deleting an Object Model 65-34
Adding Ingress and Egress Points 65-36
Creating Randomized Simulation Objects 65-43
Creating a Simulation Object Group 65-45
Setting the Simulation Connection when Creating an SOG 65-46
Navigating Among Edited Simulation Objects 65-46
Configuring Scripted Entity Movement 65-47
Configuring Ballistic Missile Movement 65-48
Configuring Animated Movement 65-50
Editing Movement File Configurations 65-51
Editing Tactical Graphics 65-53
Editing a Tactical Graphic’s Menu Icon 65-53
Setting the Default Values for Tactical Graphics Properties 65-54
Specifying the Properties that can be Edited in the Front-End 65-55
Editing the Visual Model for a Tactical Graphic 65-56
This section explains how to edit the parameters that are common to most objects. The procedures in this section apply to simulation objects, tactical graphics, cultural features, and other objects such as weather and contamination areas.
If one of the object parameters described in this section does not apply to a particular object type, it is either blank or uneditable in the Simulation Object Editor.
To select an object to edit:
Optionally, in the object list, select the category for the type of object you want to edit.
Select the object in the list.
Objects are organized by categories on the Create menu and the object creation palettes. You can change the categories that an object is part of. For details about adding new categories to the list, please see “Adding a New Category,” on page 64-20.
The Simulation Object Editor lets you change an object’s object type (DIS/RPR enumeration) and matching type. (For details about published and matching object types, please see “Published Object Types and Matching Object Types,” on page 69-6.) You might want to or have to do this for any of the following reasons:
If you create a new model, you must specify an entity enumeration (Object Type). (The Simulation Object Editor automatically constructs a Matching Type whose Domain and Kind field match the Object Type and whose other fields are wild cards.)
You might want to change an existing object’s enumeration.
You might want to change an object’s matching object type.
The Entity Enumeration value displayed in the Simulation Object Editor is the 7-digit DIS or RPR FOM enumeration that VR-Forces uses to build the published object type. The matching object type is not displayed in the Simulation Object Editor, but you can specify it in the Change Enumeration dialog box as described in this procedure.
To change an object’s enumeration:
Select the object in the object list.
Click Edit next to the Entity Enumeration text box (Figure 65-2). The Change Enumeration dialog box opens (Figure 65-3).
Figure 65-2. Object enumeration
Edit the enumeration by selecting options from the lists for enumeration elements or type a new enumeration in the Object Type text box.
Optionally, specify the Matching Type as follows:
Click Advanced. The dialog box expands (Figure 65-4).
For each field in the matching type enumeration that you want to be a wild card (-1), select the appropriate check box.
Optionally, clear the Apply Change to All Matching Subordinate Types check box. Usually you will want an enumeration change to affect all cases where this simula- tion object will be created. However, if there is some reason that you want an enumeration change to not affect simulation objects created as part of a unit, you can do that by clearing this check box. A more straightforward approach would be to create a new simulation object from the existing simulation object rather than changing the enumeration.
Click OK. The enumeration changes.
To change an object’s name:
Select the object in the object list.
Type a new name in the Name text box (Figure 65-2).
Figure 65-5. Can Create Object check box
You can specify which of the object creation palettes an object should be listed on.
To specify the object creation palette for an object:
Select the object in the objects list.
In the Palette list (Figure 65-5), select the palette you want to put it on.
When an object gets created, it gets placed on an overlay. By default, the object is placed on an overlay that has the same name as the object creation palette from which it is created. You can create additional default overlays and assign them to objects. You can still assign the object to a different overlay when it gets created. For details about over- lays and assigning objects to them, please see “Creating and Editing Overlays,” on page 38-2 and “Specifying an Object’s Properties Before You Create It (Click to Locate),” on page 16-13.
To specify the default overlay:
Select the object in the objects list.
Select an option from the Default Overlay list (Figure 65-5).
To add a default overlay:
Choose Edit Default Overlay Layers. The Overlay Layers dialog box opens.
Click Add. The New Overlay Layer dialog box opens.
Type a name for the layer.
Click OK. The layer is added to the list in the Overlay Layers window.
Click OK. The overlay is now available in the Default Overlay list.
You cannot change the platform for existing simulation objects or new objects created from existing models. You can only specify the platform for new models that are not created from existing models. For details, please see “Creating a New Simulation Object,” on page 65-32.
If you have made changes to an object and have not yet saved the simulation model set, you can revert to the original simulation object configuration. You can revert an object at any time prior to saving the SMS, regardless of how many other objects you may have changed since you edited the simulation object you want to revert.
To undo changes to an object:
Select the object in the object list.
Choose Model Revert Model.
You can also apply a country to humans and cultural features if they are specific to a country.
The Used By Countries list works exactly like the Categories list. For details about how to configure the list of countries, please see “Editing the Category List,” on page 64-19.
To assign a simulation object to a country of use, in the Used by Countries list (Figure 65-1), select the check boxes for the countries that use it.
If you add a new model by copying another model, you may want to quickly clear the Used By Countries list before selecting the countries for the new model. (You can clear the other lists the same way.)
To clear the Used by Countries list, click the Clear button ( ) at the top of the list.
You can set the bounding volume in the following ways:
Edit the value manually.
Calculate the bounding volume of a particular entity based on the model.
Calculate the bounding volumes for all entities based on their models.
The bounding volume is not the same thing as the selection box that is displayed around a simulation object when you select it. The selection box is just part of the front-end display. The bounding volume is used by the simulation engine.
You can exclude individual entities from the global updates.
VR-Forces calculates the bounding volume for units based on the loca- tions and bounding volumes of the members of the unit.
To change an entity’s bounding volume manually:
Select the entity you want to edit in the object list.
Change any of the values in the Size group box (Figure 65-6).
To calculate the bounding volume of an entity from its model, click the Calculate Support Points and Bounding Volume from Displayed Model button 
) or the Calculate Bounding Volume from Displayed Model button ( ).
To calculate the bounding volume for all entities, choose Model Compute Bounding Volume and Support Points.
You must run VR-Forces at least once before you can display bounding volumes in the Simulation Object Editor.
To display a simulation object’s bounding volume:
Select the entity in the object list.
In the Visual Model group box, on the Model Sets list, select 3D Models.
Select the Bounding Volume check box. The bounding volume is displayed (Figure 65-7).
Support points are the locations on a model that contact the ground. You can specify support points in any of the following ways:
Set them manually.
Calculate the support points for all entities based on their models.
To specify support points manually, in the Size group box (Figure 65-6), type the desired values.
To calculate support points based on the model, in the Size group box, click the Calculate Support Points and Bounding Volume from Displayed Model button ( ) or the Calculate Support Points from Displayed Model button 
).
To calculate the support points for all entities, choose Model Compute Bounding Volume and Support Points.
If you run the Compute Bounding Volume and Support Points command, it updates all entities. If you have specified the bounding volume or support points for an entity manually, this operation might override those settings. You can exclude individual enti- ties from the global update process.
To exclude an entity from the global update process:
Select the entity in the object list.
In the Size group box, select the Exclude From Batch Update check box.
The Sensor Signature parameters specify the distance at which other simulation objects can sense the simulation object you are editing. By contrast, the sensor systems on the simulation object control its ability to sense other simulation objects. For more information, please see “Editing a Simulation Object’s Systems,” on page 65-28.
To edit simulation object parameters, edit any of the parameters in the Attributes panel (Figure 65-8). (The panel reconfigures itself as you select different types of simulation objects.)
Size
Movement
Sensor Signature
Object geometry is to an entity as terrain is to the earth. It allows embarked entities to move about on the entity on which they are embarked. For example, adding object geometry to an aircraft carrier lets planes taxi on the deck of the carrier. You can add object geometry to entities in the Simulation Object Editor. Object geometry must be in OpenFlight, MEDF, or GDB format. OpenFlight geometry gets converted to GDB and saved. For complete details about adding object geometry and generating naviga- tion data, please see “Generating Navigation Data for Entities,” on page 58-9.
When you edit an entity’s embarkation points and slots, the model used is the visual model. This will not necessarily line up with the object geometry for that entity, if it has any.
To add object geometry to an entity:
Select the entity in the Object List.
In the Movement group box (Figure 65-8), select Use Detailed Geometry in Simu- lation Engine.
Click Select. The Select Object Geometry dialog box opens.
Click the Browse button. The Object Geometry dialog box opens.
Select the file that contains the object geometry for this entity.
Click Open.
Click OK.
You can specify that cultural features be aligned to the terrain (ground clamped). If they are not aligned to the terrain they might end up sticking out at odd angles.
Figure 65-9. Is Gravity Aligned check box
To align cultural features to the terrain, select the Is Gravity Aligned check box (Figure 65-9).
To specify the default DI-Guy characteristics for a lifeform:
In the Categories list, select the Human or Animal category.
Select a lifeform in the object list.
In the Visual Model group box, on the Model Sets list, if 3D Models is not selected, select it.
In the Visual Model group box, click Edit. The Modify Visuals dialog box opens (Figure 65-10). The Use DI-Guy option should be selected. If it is not selected, select it.
Optionally, filter the options available in the lists, as follows:
Click Filter. The DI-Guy Filters dialog box opens.
Select an option for each characteristic that you want to filter on.
Click OK.
Select the DI-Guy character you want to use from the Character Type list.
Select the default appearance from the Default Appearance list. One of the default options is to use a random appearance.
If you selected random appearance, optionally, specify the list of appearances to choose from. For details, please see “Configuring the Random DI-Guy Character- istics Lists,” on page 65-17.
Optionally, in the Default Hand Item list, select a hand item. If you choose random, click Random Hand Item List to specify the hand items that can be chosen.
Optionally, in the Default Head list, select a head. If you select random, you can specify the list of heads to choose from. If you choose random, click Random Head List to specify the heads that can be chosen.
Select the default animation from the Default Animation list. The default anima- tion is the animation the entity uses if it is not tasked and if it has a posture and speed that is appropriate to the animation.
To configure the DI-Guy characteristics lists:
In the Categories list, select the Human category (or Animal category).
Select a lifeform in the object list.
In the Visual Model group box, on the Model Sets list, if 3D Models is not selected, select it.
In the Visual Model group box, click Edit. The Modify Visuals dialog box opens (Figure 65-10). The Use DI-Guy option should be selected. If it is not selected, select it.
Click the random list button for the characteristic you want to configure. A dialog box opens (Figure 65-11). The options available for the character type are listed.
Optionally, filter the list by selecting options in the filter lists.
Select the options that you want to include in the random list.
Clear any options that you do not want to include in the random list.
Click OK.
Click OK to close the Modify Visuals dialog box.
The Visual Model Editors dialog box allows you to configure all aspects of entity visual- ization, including the 2D icon and 3D model used. (For details, please see Chapter 81, Model and Element Definitions.) However, the Simulation Object Editor lets you quickly and easily change the 3D model or 2D icon used to represent a simulation object. When you change a model in the Simulation Object Editor, the entity’s model definition also gets changed.
To change the visual model for a simulation object:
In the object list, select the object list whose model you want to change. The model for the currently selected model set is displayed in the Visual Model group box.
The visual model window responds to the same keyboard and mouse controls as the front-end.
In the Model Set list in the Visual Model group box, select the model set that you want to edit for this simulation object.
Optionally, select a visual type in the Visual Type list. This choice changes the 3D model for any simulation object that is using a generic model. If a simulation object has a specific model, changing the visual type does not affect it.
Change the 3D model, 2D icon, or 2D image as described in the following sections.
To change a 3D model or 3D colorized model:
Click Edit. The Modify Visuals dialog box opens (Figure 65-12).
If the dialog box has options for 3D Models or DI-Guy, select Use 3D Model. The Modify Visuals dialog box lists available models (Figure 65-12). (You can add new models. For details, please see “Adding a New Visual Model or Image,” on
page 65-24.)
Select the model that you want to use. The new model is displayed in the panel.
By default, the Modify Visuals dialog box tries to filter the list to show only the type of entity that you are editing. If you do not see the models you expect to see in the list, particularly if you know that the models are available in the ./data directory, try changing the filter. For example, surface entities are of type Watercraft, while subsurface entities are of type Entity.
Click OK to close the Modify Visuals dialog box.
To change a 2D icon using the MIL-STD font:
Be sure that the Edit Spot Report Models check box is cleared.
Select the simulation object whose icon you want to edit.
In the Visual Models group box, in the Model Sets list, select 2D Icons.
Click Edit. The Modify Visuals dialog box opens (Figure 65-13).
Select the Use MIL-STD Font option. The dialog box lists index values and associ- ated glyphs.
Select the icon glyph that you want to use. The new icon is displayed in the panel
Click OK to close the Modify Visuals dialog box.
When you change the 2D icon for a simulation object, the spot report icon for that object does not change. You can change the icon manually, as described in “Editing a Spot Report Icon,” on page 65-23, or you can automatically update spot report defini- tions.
To regenerate spot report definitions:
Choose File Regenerate Spot Report Definitions. A prompt opens.
Click Yes.
To change a 2D icon using an image:
Be sure that the Edit Spot Report Models check box is cleared.
Select the simulation object whose icon you want to edit.
In the Visual Models group box, in the Model Sets list, select 2D Icons.
Click Edit. The Modify Visuals dialog box opens (Figure 65-13).
Select the Use Image option. The dialog box lists the forces that are configured for this simulation model set (Figure 65-14).
Click the Edit button for the force whose icon you want to change, or to choose the same image for all forces, click Select for All. The Select Model Definition dialog box opens (Figure 65-15). It lists the available images. By default the list is for MIL-STD 2525a icons. (You can add new images. For details, please see “Adding a New Visual Model or Image,” on page 65-24.)
Select the image that you want to use. The new image is displayed in the panel.
Click OK.
Click OK to close the Modify Visuals dialog box.
When the Edit Spot Report Models check box is selected, you can only edit spot report icons. To edit any other visual model, clear the check box.
To edit a spot report icon:
In the Visual Models group box, select the Edit Spot Report Models check box. If the model set is not already 2D Icons, it changes to 2D Icons and the window shows the icons for this simulation object.
Click Edit. The Modify Visuals dialog box opens (Figure 65-13).
Follow the directions for changing a 2D icon, as described in “Changing the 2D Icon Using a Font,” on page 65-21 or “Changing the 2D Icon Using an Image,” on page 65-21Changing the 2D Icon Using a Font or Changing the 2D Icon Using an Image.
To add a new model or image to the visual models list while editing a simulation object:
In the object list, select the object whose model you want to change. The model for the currently selected model set is displayed in the Visual Model group box.
In the Visual Model group box, in the Model Sets list, select the model set that you want to edit.
For 3D models or 3D colorized models:
Click Edit. The Modify Visuals dialog box opens (Figure 65-12).
Click the Add button ( ). The Model Definition dialog box opens. This is a standard file chooser dialog box.
For 2D icons, do the following:
Click Edit. The Modify Visuals dialog box opens (Figure 65-13).
Select the Use Image option. The dialog box lists the forces that are configured for this simulation model set.
Click the Edit button for the force to which you want to add an image. The Select Model Definition dialog box opens (Figure 65-14).
Select the file for the model that you want to add to the list. It must be a model or image type that VR-Forces supports. (This file becomes the value for the filename attribute of the model definition.)
Click OK. The Model Definition Name dialog box opens.
Type a name for the model definition.
Click OK.
Click OK to close the Modify Visuals dialog box.
You can add model definitions in the Simulation Object Editor independently of any simulation object just as you can in the Visual Model Editors dialog box. The only attribute that you can set is the filename. However, in many cases that is the only attri- bute you need. If you need to specify other attributes, you must use the Visual Model Editors dialog box.
To add a model definition independently of editing a simulation object:
Choose Edit Add Model Definition. The Add Model Definition dialog box opens.
Click the Add button ( ). The Model Definition dialog box opens. This is a stan- dard file chooser dialog box.
Select the file for the model that you want to add to the list. It must be a model or image type that VR-Forces supports. (This file becomes the value for the filename attribute.)
Click OK. The Model Definition Name dialog box opens.
Type a name for the model definition.
Click OK. The new model definition is added to the list.
Click OK to close the Add Model Definition dialog box.
Display Models check box. Enables or disables display of the visual model.
Daylight check box. Changes the lighting of the model between noon and 9 P.M.
Marker Labels check box. Displays labels for the markers for sensor and weapon positions.
Model Sets. Specifies which model set to use to display the entity.
Switch Node States. Displays the different switch nodes for the model, if appli- cable.
View. Perspective view or view the model from the specified side (left, front, top, and so on.)
You can import visual models (element definitions, model definitions, and object type mappings) into an SMS. You might want to do this if you have edited an SMS and then decide that you need to revert to a previous version that you have saved in ./factory or elsewhere. When you import visual models, the imported model definitions replace any matching definitions in the SMS. The import operation imports all leaf files in the selected directory.
To import visual models:
Choose File Import Visual Models. A confirmation prompt opens.
Click Yes. A file chooser dialog box opens.
Select the directory from which you want to import visual models.
Click Choose.
Pruning visual models (element definitions, model definitions, and object type mappings) removes duplicate visual models from the set of leaf files that get loaded for an SMS. This improves the load time in the SOE and when you load a scenario.
Pruning only affects the SMS-specific definitions files. It does not touch any additional definition files that may have been saved from the Visual Model Editors dialog box.
To prune visual models:
Choose File Prune Visual Models. A confirmation prompt opens.
Click Yes. A file chooser dialog box opens.
Select the directory from which you want to import visual models.
Click Choose.
When you update an SMS, you can export the visual models (element definitions, model definitions, and object type mappings) to a directory other than the default directory in the SMS. This would typically be done for archival purposes, such as updating the files in ./factory.
Only the SMS-specific definitions files get exported. If user-created leaf files were previ- ously loaded, the definitions do not get exported back to those leaf files. They get included in the SMS-specific files.
To export visual models:
Choose File Export Visual Models. A confirmation prompt opens.
Click Yes. A file chooser dialog box opens.
Select the directory to which you want to export visual models.
Click Choose.
If you update the visual models associated with simulation objects and you have a scenario open, you can refresh the models used in the scenario without shutting down VR-Forces.
To refresh visual models, choose Settings Reload Visuals.
Simulation objects have complex capabilities, such as the ability to move, to take damage, to sense other simulation objects, and to fire munitions. These capabilities are organized as systems. You can quickly change how a simulation object functions by adding, removing, and changing its systems. The Simulation Object Editor lists the systems available in each category and only lists systems that are appropriate for the entity type (Figure 65-16). For example, a lifeform can have an M-16 or an RPG, but not a cruise missile.
Add System Remove System Edit Properties Open OPD Editor
Some systems are interdependent. For example, if you add a weapon system to a simu- lation object, it probably cannot use it unless it also has a sensor system so that it can detect simulation objects. If you change or add systems, it is up to you to know if they have dependencies.
The components that make up a system have parameters and you can edit the parame- ters of system components by editing the properties of the system.
The Simulation Object Editor lets you edit the following types of systems:
Damage. You can specify the type of damage model that a simulation object uses. When you select a damage model, the Simulation Object Editor configures the damage files that are appropriate for the object type.
Sensors. You can specify the sensors that a simulation object uses to locate other simulation objects in the simulation. (By contrast, sensor signatures, which you can also set, specify the distance at which other entity sensors can locate this simulation object. For a list of the sensor signatures used for VR-Forces by category, please see Table 71-1.) When you add a weapon, the Simulation Object Editor configures the components and connections necessary for the sensor to work.
Weapons. The Simulation Object Editor lists the weapon systems that are appro- priate for the object type. When you add a weapon, the Simulation Object Editor configures the components, targets, ammunition, and connections necessary for the weapon to work.
Other systems. This category includes spot reports and IFF transponders.
There is no specific limit to the number of sensors, weapons, or other systems that you can configure for a simulation object.
To add a system:
Click the Add System button 
) for the system type you want to add. The Add System dialog box opens (Figure 65-17). It lists the systems of this type that are available for the simulation object you are editing. If you select a system in the window, the dialog box displays a brief description.
Select the system you want to add.
Click OK. The system is added to the list in the Simulation Object Editor.
You can only have one damage model specified for a simulation object.
To specify a damage model, select an option from the Damage list.
You can only have one movement model specified for a simulation object.
To specify a movement model, in the Movement group box, select an option from the Movement Dynamics list.
Some systems have properties that you can edit.
To edit a system’s properties:
Select the simulation object whose system you want to edit.
For sensors, weapons, or other systems, select the system whose properties you want to edit. (You do not have to select the damage or movement model, because there can only be one.) If the system has properties, the Properties button is enabled.
Click the Edit Properties button 
). A Properties dialog box opens. The 3D model in the Visual Models group box displays a green dot on the simulation object where the system is located. In some cases there are multiple locations.
Optionally, in the Visual Models group box, select the Marker Labels check box. A label is added to the green dot to identify it.
Edit the properties as desired.
Click OK.
!
!
Before you jump to the OPD Editor, save any changes that you have made to the simulation model set. If you make any changes in the OPD Editor, the Simulation Object Editor is automatically updated after you save the changes in the OPD Editor.
To jump to a system in the OPD Editor:
Save your changes to the SMS.
Select the system that you want to edit.
Click the Open OPD Editor button ( ) next to the system.
Editing Simulation Object Models — Creating a New Simulation Object
You can remove sensor, weapon, and additional systems.
If you remove a system that another system depends on, the other system will not work. It is your responsibility to know these dependencies.
To remove a system:
Select the system you want to remove.
Click the Remove System button 
).
You can create a new simulation object by using an existing object as a template or by building a completely new object.
The procedure for creating a new unit is largely the same as for creating a new entity. The main difference is that units do not have 3D models and when you create a unit, you specify its subordinates.
To create a completely new entity:
Choose Model New Model. The Create New Entity dialog box opens (Figure 65-18).
Select a platform type.
Optionally, select a template. (Templates are specific to a platform type. There might not be a template for some platforms.)
Type a name for the entity.
Editing Simulation Object Models — Creating a New Simulation Object
Optionally, click Edit and specify the object type. You can do this after you create the entity if you want to. You can also just accept the object type supplied by VR- Forces.
Click OK. The Simulation Object Editor adds a new entry to the object list. The editor shows default values for all the fields.
Optionally, edit the enumeration.
Optionally, specify that this entity is a favorite.
Specify 2D and 3D visual models.
Specify appropriate values for the entity parameters.
Type a name to be used in the entity’s label (marking text) in the Short Name text box.
Specify a movement system.
Specify a damage model.
Optionally, add weapon systems.
Optionally, add sensors.
Save the simulation model set.
If you create a new simulation object model from an existing model, the new model starts with all of the behavioral characteristics and systems of the original one. It incre- ments the object enumeration. You just have to name it and customize it for the new simulation object.
i You can use this procedure to create new units.
Editing Simulation Object Models — Deleting an Object Model
To create a new simulation object model from an existing model:
In the object list, select the source object.
Choose Model New Model from Existing. The Create New Model dialog box opens.
Type a name for the model.
Optionally, edit the enumeration.
Click OK. The new simulation object is added to the object list. If you did not edit the enumeration, the original enumeration is incremented. A .entity file is created based on the name.
Edit the parameters to provide the new simulation object the characteristics you want for it.
Save the simulation model set.
To delete an object model from a simulation model set:
Select the object in the object list. (You can select multiple models using the Shift
or Ctrl keys.)
Choose Model Delete Model or press Delete.
If an entity allows other entities to embark on it, you can configure:
Allowed entity types. The types of entities that can embark.
Slots. The location on an entity where embarked entities move to. The number of slots on an entity controls how many entities can embark on it using the Embark task. For entities that are visible when they are embarked, such as humans on a truck or aircraft on an aircraft carrier, it is important to specify sensible looking slots.
Ingress points. The locations on an entity where entities embark before moving to a slot.
Egress points. The locations on an entity from which entities disembark.
Units can support embarkation, but the usual use of embarkation is for entities to embark on other entities. In entity-level scenarios, if a unit embarks, the individual members of the unit carry out the embarkation task.
To configure embarkation for an entity:
In the Attributes panel, if Can Be Embarked Upon is not selected, select it.
Optionally, select Can Be Moved Onto For Embark. This option lets ground- clamped entities identify entities that they can embark on. They can then walk or drive onto the entity and automatically become embarked.
Click Configure. The Configure Embarkation dialog box opens (Figure 65-19).
Click Add. The Add Type dialog box opens.
Select a type of entity that can embark.
Optionally, add additional entity types.
For each entity type listed, specify ingress and egress points. Values are in meters relative to the center of the parent entity. For more information, please see “Adding Ingress and Egress Points,” on page 65-36.
Optionally, configure slots. For more information, please see “Configuring Slots,” on page 65-38.
Click OK.
An egress point specifies where an entity disembarks from the parent entity.
You can specify that an ingress point should only support some of the slots on the entity. You might want some types of entities embarking at one ingress point and moving to certain slots, while other entities embark at a different location and use other slots. For example, if you are simulating a ferry, cars and trucks would enter at the front or rear and move below deck. Foot passengers would enter at the sides and move to the passenger decks.
When you add an allowed entity type, the Simulation Object Editor automatically creates a slot for that entity type. The ingress and egress points that you configure for that entity type on the basic version of the Configure Embarkation dialog box are auto- matically associated with the same slot.
In Advanced mode, you can add additional ingress and egress points and associate them with whichever slot you want. You do not have to add them in pairs.
This procedure describes configuring an ingress point. To configure an egress point, substitute egress for ingress in each step.
Click Configure. The Configure Embarkation dialog box opens (Figure 65-19).
Click Advanced. The dialog box redisplays.
Click the Add button ( ) above the Ingress Points list. An ingress point is added to the list. A vertex is added to the display window at the center of the entity bounding volume (Figure 65-20). The coordinates for the ingress point are displayed at the bottom of the dialog box.
Double click the X value for the Ingress point to make it editable.
Enter the X value.
Repeat for the Y and Z values.
If you want to specify a path for the embarking entity
Click the Add button for the Ingress Point coordinates list. A new coordinate is added.
Specify the X, Y, and Z values for the new coordinate. The path is displayed in the window (Figure 65-21).
Optionally in the Supported Slots field, type the numbers for the slots that should support this ingress point. If you leave the field blank, it supports all slots. If you specify more than one slot, separate the numbers with space.
To change the side of a parent simulation object that the embarked simulation objects exit on, select the Flip Disembark Body X check box, the Flip Disembark Body Y check box, or both (Figure 65-22).
Click OK.
The Simulation Object Editor adds a slot to the embarkation configuration for each allowable object type that you add. The slot is configured with the object type of the allowable object type. You can configure several parameters for the slots. You can add and remove slots with the Add and Remove buttons.
Click Configure. The Configure Embarkation dialog box opens (Figure 65-19).
Click Advanced. The dialog box redisplays.
Select the slot that you want to edit. The dialog box redisplays to show the slot’s parameters (Figure 65-22).
Optionally, configure Slot Exclusions. For details, please see “Configuring Slot Exclusions,” on page 65-40.
To change the side of a parent simulation object that the embarked simulation objects exit on, select the Flip Disembark Body X check box, the Flip Disembark Body X check box, or both.
If you have added a new slot, in the Object Type field, specify the object enumera- tion for the type of simulation object that can use this slot. If this is a previously created slot, you can edit the object type. You can configure different object types in different slots on a simulation object.
If you want to give the slot a name, type it in the Slot Name text box.
If you want to categorize this slot as a specific named type (a text string, not an object type enumeration), type it in the Slot Type text box.
In the Position group box, specify the location of the slot relative to the center of the entity’s bounding volume.
In the Orientation group box, specify the orientation of the slot relative to the center of the entity.
Click Change Appearance and specify the appearance of the simulation object type when it is in the slot. For example, a human embarked on a truck might have its posture set to Sitting.
If you want the embarked simulation object to immediately jump to the slot, select Jump To Location. If this check box is clear, the simulation object will move to the slot. For example, an aircraft will taxi to a slot on a carrier deck.
If you want the embarked simulation object to have the same heading as the parent entity, select Turn To Heading.
If you want the embarked simulation object to be invisible in 3D observer modes, select Invisible When Embarked.
Specify the number of entities that can use this slot.
A slot exclusion specifies that if a given slot is occupied, other slots cannot be occupied. For example, an entity might allow both tanks and dismounted infantry entities to embark. If no tanks are embarked, the entity can hold 20 DIs. But if a tank is embarked, it uses up 10 slots and now only 10 DIs can embark.
To configure slot exclusions:
On the Slot Exclusions line, click Edit. The Edit Slot Exclusions dialog box opens (Figure 65-23).
Figure 65-23. Edit Slot Exclusions dialog box
Click the Add button ( ). A blank line is added to the list.
Double-click the cell in the Slot Is Filled column. The cell becomes editable.
Type the number of the slot that you want to configure.
Double-click the cell in the Exclude Slots column.
Editing Simulation Object Models — Configuring Wakes
Type the numbers of the slots that cannot accept entities if the slot you are config- uring is filled. You can enter more than one slot to be excluded. Separate the slot numbers with a space.
Repeat this procedure to add additional exclusions. You can also edit existing exclu- sions and delete them.
Editing Simulation Object Models — Configuring Wakes
To configure wakes:
Select a surface entity in the object list.
Click the Edit button next to the Wake Model label. The Edit Wake Model dialog box opens (Figure 65-25).
Change wake parameter values as desired. For details about wake parameters, please see “Configuring Wakes,” on page 83-14.
To see the effect of parameter changes under different sea conditions:
Choose Edit Ocean Settings. The Ocean Settings dialog box opens.
Adjust the wind speed, wind direction, and choppiness values.
Click OK.
Click OK.
Editing Simulation Object Models — Creating Randomized Simulation Objects
A randomized simulation object is an object that you can use to quickly add a generic simulation object type, such as a civilian vehicle or commercial aircraft, using randomly chosen specific models of these object types. For example, if you want to add several cars to a scenario, you could individually select a Nissan Maxima, a Toyota Corolla, a Honda Accord, and so on, and add them to the scenario. Or you could select a random- ized simulation object that references a list of civilian vehicles and click multiple times on the terrain, With each click a randomly chosen vehicle would be added to the scenario.
You create randomized simulation objects in the Simulation Object Editor. You can create them in entity-level and aggregate-level scenarios.
To create a randomized simulation object:
Start the Simulation Object Editor.
Load the SMS you want to use.
Choose Model New Randomized Simulation Object. The Randomized Simulation Object dialog box opens.
Type a name for the simulation object. The new object is added to the object list.
Select the new object in the object list (Figure 65-26).
Optionally, edit the common simulation object attributes, such as category, palette, default overlay, and so on.
Click the Add button (Figure 65-26). The Add to Randomized Simulation Object dialog box opens.
Editing Simulation Object Models — Creating Randomized Simulation Objects
Select the simulation objects that you want to be part of this randomized simula- tion objects. To select an object, double-click it or select it and click Add. As you select objects, they are added to the list (Figure 65-27). If you want the probability of a particular simulation object being created to be higher than others, add multiple instances of the same simulation object to the list.
Click Close.
Save the SMS.
Editing Simulation Object Models — Creating a Simulation Object Group
You create simulation object groups (SOGs) in the Simulation Object Editor. You specify the members of the SOG in a version of VR-Forces that gets launched from the Simulation Object Editor. When the Simulation Object Editor launches VR-Forces, it needs to use a simulation connection. For details about setting the simulation connec- tion, please see “Setting the Simulation Connection when Creating an SOG,” on
page 65-46.
Simulation objects groups are saved with the extension .sog.
To create a simulation object group:
Start the Simulation Object Editor.
Load the SMS you want to use.
Choose Model New Object Group. The New Object Group dialog box opens.
Type a name for the new SOG.
Click OK. The new group is added to the objects list and the Simulation Object Editor displays a simulation object group page.
Specify the category, creation palette option, and other generic information as you would for any simulation object.
Optionally change Creation Options and the altitude offset.
Click Launch Object Group Editor. You are prompted to save your changes to the SMS.
Click Yes. A limited version of VR-Forces opens. It has a green terrain grid.
Use the object creation palettes to add objects to the SOG as you would for a scenario. You can change to Stealth observer mode if you want to view the terrain in 3D. It is a flat terrain.
When you add objects to an SOG, they are placed on overlays, just as when you add objects to a scenario. There may be cases where you add tactical graphics to an SOG, but do not want them to be displayed when you place the SOG in a scenario. For example, you might put routes on the deck of an aircraft carrier, but do not want to clutter up the display with them. If you edit the name of the tactical graphics overlay and put an asterisk (*) in front of the name, when the SOG is placed, the overlay will be hidden. For more information, please see “Hiding an Overlay by Default,” on page 38-4.
Choose File Save Object Group to save the SOG and continue editing. Choose
File Save Object Group and Exit to save the SOG and close VR-Forces.
Editing Simulation Object Models — Navigating Among Edited Simulation Objects
When you create an SOG, the Simulation Object Editor starts VR-Forces so that you can specify the members of the SOG. By default it uses the DIS localhost connection for EntityLevel.sms and the HLA 1516 Evolved RPR 2.0 with MAK extensions connec- tion for AggregateLevel.sms. You can change the connection if you want to.
To set the simulation connection when specifying the members of a simulation object group:
In the Simulation Object Editor, choose Edit Object Group Connection. The Choose Connection dialog box opens.
Select the connection you want to use.
Click OK.
Figure 65-28. Forward and Back arrows
In most cases, simulation objects move based on the intelligence built into their compo- nents – sensors, controllers, and actuators. However, there are two instances in which entity movement follows a predetermined sequence, or script. These cases are ballistic missile movement and animated movement tasks.
Ballistic missile movement is configured using comma-delimited value (CSV) files. Animated movement tasks can be configured with CSV files or 3DS ASCII Export (ASE) files. We refer to these files generically as movement files.
A movement file specifies a time sequence and a set of parameters that define the entity’s movement for each time entry. Ballistic missile movement files define lateral- distance, altitude, and range. Animated movement movement files define lateral distance, altitude, range, heading, pitch, and roll.
Ballistic missile movement files get configured in a dialog box that is shared with animated movement movement files (“Configuring Animated Movement,” on page 65-50). Animated movement movement files have more parameters than ballistic missile movement files. If a ballistic missile is configured with a movement file that has these additional parameters, they are ignored.
When you create a Missile Target event in VR-Forces, you specify a missile type. Missile types are configured in the Simulation Object Editor.
To configure ballistic missiles:
Choose Edit Ballistic Missiles. The Ballistic Missiles dialog box opens (Figure 65-29).
Figure 65-29. Ballistic Missiles dialog box
In the Missile Type list, select the missile type that you want to edit. You can add, delete, and rename missile types using the Add ( ), Delete ( ), and Rename ( ) buttons.
Optionally, in the Description text box, type a description. This description gets used as a tooltip for the Missile Type in the Create Missile Target (and Edit Missile Target) dialog boxes.
In the Stages list, select the stage that you want to configure. Missiles can be single stage or multi-stage. For single stage missiles, configure Stage 1. For multi-stage missiles, use the Add and Delete buttons to add or delete stages.
For each stage, specify the following:
– Movement File. The CSV file to use. The list lists the files in ./data/simulation- ModelSets/<model_set>/scriptedObjectMovement. If you want to use a CSV file that is not listed:
Click the Add button next to the Movement File list. A file chooser dialog box opens.
Select the CSV file that you want to use. The file is copied to ./data/simula- tionModelSets/<model_set>/scriptedObjectMovement.
File Configuration. Select a file configuration from the list. File configurations specify the type of value in each column in the movement file. For details, please see “Editing Movement File Configurations,” on page 65-51.
Munition Type. The missile to use.
Clamp Type. Determines how to calculate altitude for the animation. Table 65-1 describes the clamp type options.
Completion Rule. The action to take when the movement in the CSV file is complete.
Table 65-1: Clamp type options
Option Description
Option Description
None (Geodetic) Altitude in the animation is used as altitude above the alti-
tude of the animation reference location. A constant alti- tude in the animation will result in a path that follows curvature of the earth, when a round earth terrain is being used.
None (Topographic) Altitude in the animation is used as altitude above a plane
defined by the animation reference orientation. A constant altitude in the animation will result in a straight path, even as the earth curves, when a round earth terrain is being used.
High Fidelity (Including Orientation)
Low Fidelity (Terrain Clamp Only)
Altitude Above Terrain (High Fidelity)
Ground Clamp if Altitude Offset is 0 (High Fidelity)
Altitude in the animation is ignored, and the object is ground clamped to the terrain using three support points, which will also set the orientation of the object.
Altitude in the animation is ignored, and the object is ground clamped to the terrain using only its origin point. Orientation is set solely from the animation.
Altitude in the animation is used as the altitude above the terrain height.
Acts like High Fidelity for frames where altitude is 0, and acts like None (Geodetic) for frames where altitude is non-zero.
Radar Face Cartesian Similar to None (Topographic), except the Y coordinate is
inverted. The animation would typically be started with an orientation reference corresponding to the angle of a radar face. Useful for cases where animation data is captured radar data.
Click OK.
The animated movement feature lets you script a sequence of entity movements. You can do this using a CSV file or a 3DS ASCII Export (ASE) file. VR-Forces includes some sample animated movement files.
Animated movement is assigned to an entity as a task from the Movement submenu. You configure the animated movement options in the Simulation Object Editor.
To configure animated movement:
Choose Edit Animated Movement. The Animated Movement dialog box opens (Figure 65-30).
To edit an existing animated movement, select it in the Animated Movement list. To create a new animated movement:
Click the Add button next to the Animated Movement list. The New Configu- ration dialog box opens.
Type a name for the new animated movement.
Click OK.
Optionally, type a description for the animated movement. This description is displayed in the Animated Movement dialog box when an Animated Movement task is assigned.
In the Categories window, select the categories that this animated movement applies to. Use the Add and Delete buttons to add and delete categories.
In the Movement File list, select the movement file to use. The list lists the files in
./data/simulationModelSets/<model_set>/scriptedObjectMovement. If you want to use a CSV file or ASE file that is not listed:
Click the Add button next to the Movement File list. A file chooser dialog box opens.
Select the file that you want to use. The file is copied to ./data/simulationModel- Sets/<model_set>/scriptedObjectMovement.
If you chose an ASE file, the dialog box displays a field called Animation. Select an animation from the list.
If you chose a CSV file, it displays a field called File Configuration. Select a file configuration from the list. File configurations specify the type of value in each column in the movement file. For details, please see “Editing Movement File Configurations,” on page 65-51.
In the Clamp Type list, select an option for calculating the altitude. For details, please see Table 65-1.
In the Completion Rule list, select the action you want the entity to take after it completes the animated movement task.
To create or edit a movement file configuration:
In the Ballistic Missiles dialog box or the Animated Movement dialog box, click the Edit button 
) next to the File Configuration list. The Edit Movement Data File Configurations dialog box opens (Figure 65-31).
Figure 65-31. Edit Movement Data File Configurations dialog box
Ballistic missile file configurations have four rows. Animated movement file configurations have seven rows. If you specify a seven-row configura- tion for a ballistic missile, it ignores the values that it does not use.
If you are editing an animated movement that uses an ASE file, there is no File Configuration option. This only applies to CSV files.
In the Movement File Configurations list, select the configuration you want to edit. If you are creating a new configuration, click the Add button. The New Configuration dialog box opens.
Type a name for the configuration.
Click OK.
Optionally, change the Start Row value. This is the row in the CSV file from which VR-Forces should start reading values for entity movement.
Specify the column in the CSV file that has the Time value.
Optionally, select the time unit from the list.
Repeat steps 4 and 5 for each movement parameter.
Click OK.
You can add tactical graphics and edit existing tactical graphics just like you can add and edit simulation objects. You can create a new tactical graphic from an existing one or create a new tactical graphic using one of the basic graphic types - point, route, area, symbol, box, or circle.
When you edit a tactical graphic, you can change the default characteristics of that tactical graphic. When VR-Forces users create one of these graphics, they can edit its specific characteristics as desired.
The basic procedures for adding and editing tactical graphics are the same as for adding and editing simulation objects. This section describes procedures that are specific to tactical graphics.
Most objects on the Create menu and the various object creation palettes have icons associated with them. For simulation objects, the icon is the icon used to represent them in the front-end. For tactical graphics, the icon illustrates the type of graphic. You can change the icon associated with a tactical graphic and add icons for newly created tactical graphics.
To specify the palette icon for a tactical graphic, click the Browse button ( ) for the Menu Icon line (Figure 65-5) and select the icon that you want to use.
To remove the icon associated with a tactical graphic, click the Delete button ( ) on the Menu Icon line.
When you select a tactical graphic, the Visual Model group box displays all of the prop- erties that can be set for all of the different types of tactical graphics. Properties that do not apply to the selected tactical graphic are disabled. You can set default values for all of the properties that are applicable to the selected graphic. Setting a default value does not mean that the property will be editable in the VR-Forces front-end. The properties that are editable in the front-end are determined by keywords. For details, please see “Specifying the Properties that can be Edited in the Front-End,” on page 65-55.
To set a default value for a tactical graphic property:
In the Categories list, select one of the tactical graphics categories.
In the list of tactical graphics, select the one that you want to edit. The applicable properties are enabled in the Visual Model group box (Figure 65-32).
Set the default values.
When you create a tactical graphic in the front-end, you can edit its properties, such as line style, line width, color, and fill. The properties that you can edit in the front-end are determined by keywords that you specify in the Simulation Object Editor.
The keywords are as follows:
min=<num>. Specifies the minimum number of points required to create the object.
max=<num>. Specifies the maximum number of points allowed.
nostyle. Do not allow style editing.
freehand. The object can be drawn freehand.
penstyle. The user can change line style for the object.
fill. The user can change the object’s fill.
arrow. The user can change the object’s arrow style.
arrowsize. The user can change the object’s arrow size.
When you edit a tactical graphic in the front-end, VR-Forces builds an Edit Style dialog box with the properties specified by the keywords. If no editing is allowed, it removes the Edit icon from the Edit object dialog box.
To allow a tactical graphic’s properties to be edited, type the appropriate keyword in the Keywords text box. Separate each keyword with a semi-colon (;).
To edit the visual model for a tactical graphic:
In the Categories list, select the category for the tactical graphic that you want to edit.
In the list of tactical graphics, select the one that you want to edit.
In the Visual Model group box, in the Model Sets list, select the model set that you want to edit.
Click the Edit button. The Select Schema for Model Set model_set dialog box opens (Figure 65-33).
Select the schema that you want to use.
Click OK.
To specify a texture for a tactical graphic:
In the Categories list, select one of the tactical graphics categories.
In the list of tactical graphics, select the one that you want to edit.
In the Visual Model group box, in the Model Sets list, select the model set that you want to edit.
Click the Texture button. The Select Texture dialog box opens (Figure 65-34).
Click the Browse button 
). The Select Model Definition dialog box opens (Figure 65-35).
Select the model definition that you want to use for this texture.
Click OK.
In the Select Texture dialog box, specify the width and height of the texture, in pixels.
If this is an areal graphic, specify whether or not to use the texture for the outline of the area. If you do not use the texture, a regular line is used.
Click OK.
66. Editing Units for Entity- Level Scenarios
This chapter explains how to edit units for entity-level scenarios (EntityLevel.sms) in the Simulation Object Editor.
Introduction to Editing Units 66-2
Creating a Unit for Entity-Level Scenarios 66-2
Specifying an Aggregate As Option 66-3
Changing the Order of Subordinates 66-6
Editing a Subordinate Unit 66-7
Specifying the Default Formation 66-10
Expanding and Collapsing the Display of Formations 66-10
Displaying Bounding Boxes 66-11
Laying Out a Formation Automatically 66-13
Changing a Formation’s Layout by Hand 66-13
Editing Units for Entity-Level Scenarios — Introduction to Editing Units
VR-Forces can simulate units in two different ways:
In entity-level scenarios, VR-Forces models the individual entities of a unit. Although you can aggregate them into one simulated model for movement and certain tasks, when they engage in combat, they disaggregate into their leaf-level entities and interact at the individual entity level. Units for entity-level scenarios are configured in EntityLevel.sms or SMSs based on it.
Units in aggregate-level scenarios do not model individual entities. Combat opera- tions are data-driven and are not based on individual entity interactions. Units for aggregate-level scenarios are configured in AggregateLevel.sms or SMSs based on it.
Units in entity-level scenarios and aggregate-level scenarios have many of the same parameters as individual entities. Therefore, for the most part, configuring them in the Simulation Object Editor involves the same procedures as those described in Chapter 64, The Simulation Object Editor and SMSs and Chapter 65, Editing Simulation Object Models.
The two major differences in configuring the different types of units is that units in entity-level scenarios have subordinates and formations and do not have sensors. Units in aggregate-level scenarios do not move in formation. They have sensors and they have a large amount of information about their combat capabilities, personnel, equipment, and supplies.
To create a unit for entity-level scenarios:
Follow the procedures for creating a new entity in “Creating a New Simulation Object,” on page 65-32.
Add subordinates, as described in “Adding Subordinates,” on page 66-5.
Optionally, configure formations.
Editing Units for Entity-Level Scenarios — Specifying an Aggregate As Option
i This procedure is valid for entity-level and aggregate-level SMSs.
To specify that a unit can be an option in the Aggregate As list:
Select the unit in the object list.
Select the Allow as Aggregate As Option check box.
Each unit provided with VR-Forces has a predefined set of subordinates.
The Convoy unit provided with VR-Forces is an exception to the discussion of units in this section. It does not have an Auto Aggregation Controller, which allows a unit to aggregate and disaggregate. Although you can assign this controller, it is not recommended, because the resulting behavior would be undefined.
Figure 66-1 illustrates the Simulation Object Editor with a unit selected. The Unit Composition group box is highlighted.
When you create a new unit without copying an existing unit, you must specify its subordinates. You can also edit subordinates for existing units.
To add a subordinate to a unit:
In the Unit Composition group box (Figure 66-1), click Add. The Add to Hier- archy dialog box opens (Figure 66-2).
In the list of simulation objects, select the simulation object that you want to add.
Click Add. The simulation object is added to the list in the Unit Composition window. It is also added to each formation using a default layout algorithm.
Continue to add as many subordinates as desired.
Click Close.
To remove a subordinate from a unit:
In the Unit Composition window (Figure 66-1), select the subordinate that you want to remove.
In the Unit Composition group box, click Remove. The subordinate is removed from the unit.
Replacing a subordinate is a convenient way to remove a subordinate and insert a different subordinate in the same location in one step.
To replace a subordinate:
In the Unit Composition window (Figure 66-1), select the subordinate that you want to replace.
In the Unit Composition group box, click Replace. The Add to Hierarchy dialog box opens (similar to Figure 66-2).
In the list of simulation objects, select the object that you want to add as a replace- ment.
Click OK. The new object replaces the selected simulation object in the Unit Composition window. It is also added to each formation in the location of the replaced simulation object.
The order of subordinates in the Unit Composition window determines which entity is the leader, the order in which units are placed into formation, and the succession when units are reorganized.
To change a subordinate’s position in the unit composition:
In the Unit Composition window (Figure 66-1), select the subordinate that you want to move.
In the Unit Composition group box, click Move Up or Move Down.
!
!
If you edit a subordinate unit, the changes affect all uses of that subordinate, not just the one in this particular unit.
To edit a subordinate:
In the Unit Composition window or in the Formation Editor, right-click the subordinate that you want to edit. A menu is displayed.
In the menu, choose Edit. The Simulation Object Editor redisplays to show the selected subordinate. (If the Formation Editor is open, you must close it before you can edit the subordinate.)
Figure 66-3. Forward and Back arrows
Each unit in EntityLevel.sms has the following defined formations:
Column
Line
Vee
Wedge.
The Convoy unit provided with VR-Forces is an exception to the discussion of units in this section. It does not have any formations because there is no preconceived membership in a convoy.
You can add, remove, and rename formations. You can also:
Change the layout of subordinates in a formation.
Create new formations.
Specify the default formation.
The Formation Editor allows you to change the display of formations as follows:
Expand and collapse the display of subordinate units.
Zoom in and out on the display.
Display subordinate bounding boxes.
You can also edit formations in formation files. For details, please see “Configuring Formations,” on page 73-2.
To add a formation:
In the Unit Composition group box (Figure 66-1), click Edit Formation. The Formation Editor opens (Figure 66-4).
In the Formation Editor, click Add. The Add Formation dialog box opens (Figure 66-5).
In the Formation Name box, type a name for the formation.
In the Copy Formation list, select an existing formation to copy the new formation from.
Click OK.
Edit the layout of the formation as described in “Changing a Formation’s Layout by Hand,” on page 66-13.
To remove a formation:
In the Unit Composition group box (Figure 66-1), click Edit Formation. The Formation Editor opens (Figure 66-4).
In the Formation Editor, select the tab for the formation that you want to remove.
Click Remove. The tab is removed.
To rename a formation:
In the Unit Composition group box (Figure 66-1), click Edit Formation. The Formation Editor opens (Figure 66-4).
In the Formation Editor, select the tab for the formation that you want to rename.
Click Rename. The New Name dialog box opens.
Type a name for the formation.
Click OK.
The default formation is the formation assigned to a unit when you create it in VR- Forces. The default formation is the leftmost tab in the Formation Editor.
To specify the default formation:
In the Unit Composition group box (Figure 66-1), click Edit Formation. The Formation Editor opens (Figure 66-4).
In the Formation Editor, select the tab of the formation that you want to specify as the default formation.
Click Default. The selected tab gets moved to the leftmost position.
You can expand and collapse the display of formations in the Formation Editor window. This lets you see how simulation objects are dispersed over the terrain. It can help you quickly identify any unintended variations in subordinate formations.
To expand or collapse the display of formations in the Formation Editor, click the Expand or Collapse buttons.
You can display bounding boxes for the subordinate units in a unit. This may be useful when you collapse the views of individual units, but you still want to have a sense for the area that they occupy. Figure 66-6 illustrates a unit with the display of bounding boxes off and on.
Figure 66-6. Unit bounding boxes in Formation Editor
To display or hide bounding boxes, in the Formation Editor (Figure 66-4), select or clear the Bounding Boxes check box.
You can copy formations from one unit to another. When you copy formations, the subordinates in the unit are laid out in each formation according to their order in the Unit Composition window.
To copy a formation:
In the object list, select the unit that you want to copy formations to.
In the Unit Composition group box, click Edit Formation. The Formation Editor opens (Figure 66-4).
In the Formation Editor, click Copy. The Select Formations dialog box opens (Figure 66-7).
In the Aggregates list, select the unit whose formations you want to copy.
In the window, select the formations that you want to copy.
Click OK. The formations are copied from the selected unit to the currently displayed unit.
You can automatically distribute the simulation objects in a unit into one of the built-in formations. You can specify the distance between each entity in the formation.
To lay out a formation automatically:
In the Unit Composition group box, click Edit Formation. The Formation Editor opens (Figure 66-4).
In the Formation Editor, select the tab for the formation that you want to lay out.
Click Auto Layout. The Auto Layout dialog box opens.
In the list, select a formation type.
Specify the distance, in meters, between each entity in the formation.
Click OK. The simulation objects in the unit are reorganized to the new layout.
You can lay out a formation by hand. The gridline in the Formation Editor indicates the center of the formation (Figure 66-8). This is where the unit icon is placed when the unit is collapsed or aggregated.
Figure 66-8. Formation Editor crosshair
To change a formation’s layout:
In the Unit Composition group box, click Edit Formation. The Formation Editor opens (Figure 66-4).
In the Formation Editor, select the tab for the formation that you want to lay out.
Drag each subordinate to the location where you want it to be.
When you lay out a formation you can specify that simulation objects snap to the grid. That is, they can only be placed at the intersection of vertical and horizontal grid lines. When snap-to-grid is enabled, if you want to place simulation objects more closely together than the grid allows, you can change the scale factor.
To enable snap-to-grid for entity placement, in the Formation Editor, select Snap To Grid.
Grid spacing determines the distance, in meters, between grid lines. The default is 1000 meters.
To change the grid spacing, enter a value in the Grid Spacing box.
67. Editing Aggregate-Level Objects
This chapter explains how to edit simulation objects and combat engineering objects for aggregate-level modeling.
Creating Objects for Aggregate-Level Modeling 67-3
Configuring Simulation Objects for Aggregate-Level Modeling 67-3
Aggregating Units into Higher Echelon Units 67-4
Configuring Ammunition, Weapons, and Equipment 67-5
Defining Ammunition, Weapons, and Equipment Items 67-8
Adding Assemblies to a Unit 67-13
Setting Object Parameters for Aggregate-Level Modeling 67-17
Electronic Warfare (EW) Parameters 67-23
Personnel and Equipment Parameters 67-24
Configuring Combat Engineering Objects 67-25
Editing Aggregate-Level Objects
Editing Reader/Writer Key/Value Pairs 67-26
Editing Aggregate-Level Objects — Configuring Simulation Objects for Aggregate-Level Model-
ing
Simulation objects in an aggregate-level scenario have a more complex set of parameters than simulation objects in an entity-level scenario, so ensuring consistency among similar types of simulation objects could become difficult if after creating new models you had to configure all of the parameters from scratch or if after creating a model from an existing model you had to back out all of the assemblies and parameters that you wanted to change. Therefore, VR-Forces includes templates for common entity types. If you create a new model from a template (by selecting a template and then choosing Model New Model From Existing), you know that you will have a simulation object with similar characteristics to other simulation objects of its type, that is ready to customize with assemblies or direct specification of equipment, weapons, and personnel.
Simulation objects for aggregate-level modeling (those used in the aggregate warfare model) are configured in the Simulation Object Editor (AggregateLevel.sms). Some aspects of their configuration, such as name, enumeration, and categories are the same as for simulation objects in an entity-level scenario. Other parameters, the focus of this chapter, are used in the aggregate warfare model (Figure 67-1).
Figure 67-1. Unit in AggregateLevel.sms
Editing Aggregate-Level Objects — Configuring Simulation Objects for Aggregate-Level Model- ing
The parameters for simulation objects in AggregateLevel.sms are organized into the following groups:
Physical. Overall health of the simulation object, its footprint, and sector size for each posture.
Movement. The movement system to use and how speed is modified by different postures and MOPP levels.
Sensors. Sensor systems and signatures (similar to simulation objects in an entity- level scenario) and how signatures are modified by different postures and MOPP levels.
Attack. Specifies combat power, ammunition use, weapon systems, and modifiers to combat power.
Defense. Specifies vulnerability to different types of attack and modifiers to vulner- ability.
EW. Specifies electronic warfare systems, EW defense, and dependence.
Personnel and Equipment. Lists personnel and equipment. This information is not used by the back-end in simulations. It is reported as part of the simulation object’s state information.
Supplies. Specifies the supplies a simulation object needs to move, support personnel, and carry out combat engineering operations.
Engineering. Lets you specify engineering systems.
Additional Systems. Similar to simulation objects in an entity-level scenario, this tab lets you add other systems such as spot report systems.
The individual parameters in each group are described in “Setting Object Parameters for Aggregate-Level Modeling,” on page 67-17.
To configure a simulation object, you specify values for as many of the parameters as are appropriate for the object type. However you cannot configure ammunition, weapons, and equipment (aircraft, ships, and vehicles), without first defining them.
You can aggregate simulation objects into higher echelon units. And just as with simu- lation objects in entity-level scenarios, you specify that a simulation object can be listed in the Aggregate As list by selecting the Allow as Aggregate As Option check box.
However, the aggregate-level simulation objects that are configured to use the aggregate warfare model do not have the configuration options for specifying subordinates.
Therefore, AggregateLevel.sms has a platform, Aggregate Container, for use when aggre-
gating simulation objects. The SMS has several simulation objects configured with that platform for use when aggregating simulation objects. If you want to create additional hierarchical units for aggregation, it is recommended that you use the Aggregate Container platform.
To engage in combat, simulation objects need appropriate amounts of ammunition, weapons, and equipment. When you create a simulation object in the Simulation Object Editor, you specify the amounts that it should have by selecting them from lists of the available types of these resources. The items in these lists are also configured in the Simulation Object Editor. You can configure the ammunition, weapons, and equip- ment for simulation objects directly for each entity, or you can simplify the process by creating assemblies.
For example, a U.S. armored cavalry troop (AR CAV TRP US) has 9 M1A2s, 13 M3A3s, and 2 M1064 vehicles. An M1A2 has a 120mm gun, a 12.7mm machine gun, and 2 7.62 mm machine guns. An M3A3 has 2 TOW missiles, a 25mm gun, and a 7.62mm machine gun. An M1064 has a 120mm mortar and 12.7mm machine gun. Therefore, the entity as a whole has 26 TOW missiles, 13 25mm guns, 9 120mm guns, 11 12.7mm machine guns, 31 7.62mm machine guns, and 2 120mm mortars (Figure 67-2).
AR CAV TRP US Unit
ATGM TOW (26)
Gun 25mm (13) Weapons
Gun 120mm (9)
Gun 120mm (9)
MG 12.7mm (11)
MG 12.7mm (11)
MG 7.62mm (31)
MG 7.62mm (31)
Mortar 120mm (2)
Mortar 120mm (2)
Figure 67-2. Anatomy of a unit without using assemblies
To configure this unit directly, you would go to the Personnel and Equipment tab in the Simulation Object Editor and select all these weapons in the Weapons list and enter the amounts for each. You would also have to add up all the ammunition required by these weapons and enter them on the Attack tab.
This configuration method works fine for simple units and individual entities. However, if you had to calculate weapons and ammunition at this level of granularity for all units, it could become a tedious and error-prone activity. However, there is an alternative to directly configuring all ammunition, weapons, and equipment individu- ally. You can create assemblies. Assemblies are resources such as complete weapons, vehicles, or even small units, such as platoons. They are a convenient way to package ammunition, weapons, and equipment to more easily add them to units.
Each assembly configures the ammunition and weapons it needs for one instance of the resource, such as an M1A2. When you create a unit, you just give it the assemblies it needs. Their capabilities are “rolled up” to define the total amount of resources for the entity.
Figure 67-3 illustrates the anatomy of an AR CAV TRP US entity that uses assemblies to represent M1A2, M3A3, and M1064 vehicles. Each assembly specifies its weapons and ammunition. When you configure the AR CAV TRP US, you just specify that it has 9 M1A2, 13 M3A3, and 2 M1064 assemblies. You roll up the assemblies and the Simulation Object Editor calculates the number of each type of weapon needed (Figure 67-4).
M1064
M1064
AR CAV TRP US Aggregate
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2 (9)
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2 (13)
M1064 (2)
Assemblies
M1A2
M1A2
M1A2
M1A2
M1A2
M1A2
Gun 120mm
Gun 120mm
ATGM TOW (2)
ATGM TOW (2)
Mortar 120mm
Mortar 120mm
Weapons
MG 12.7mm
MG 12.7mm
Gun 25mm
Gun 25mm
MG 12.7mm
MG 12.7mm
(per assembly)
MG 7.62mm (2)
MG 7.62mm
MG 7.62mm (2)
MG 7.62mm
Figure 67-3. Anatomy of a unit using assemblies
Figure 67-4. AR CAV TRP US weapons rolled up on Personnel and Equipment tab
Using assemblies, the process for configuring units is to:
Define the weapons, equipment, and ammunition that units can use.
Define assemblies.
Create a unit.
Specify the unit’s assemblies.
Roll up the assemblies.
Configure all other parameters.
For more information about assemblies, please see “Assemblies,” on page 67-10.
Each ammunition, weapon, and equipment item that you want to be available for use by simulation objects is defined as a key/value pair. The key can be any text string you want to use. There is no relationship to any underlying VR-Forces code. The value is a Display Name – the string used in lists when creating assemblies or adding resources directly to a simulation object.
For each ammunition key/value pair you also must specify a type, where the types are:
Anti-air
Anti-personnel
Anti-ship
Anti-tank
Biological
Chemical
High explosive
Nuclear
For weapon system.
Use the anti-air, anti-personnel, anti-tank, and anti-ship categories for ammunition that will be used by assemblies or added directly to a simulation object. Use For Weapon System for any type of ammunition that will be used by a weapon system that must be added to a simulation object, such as a missile system, a guided bomb, or indirect fire system.
For each weapon and equipment key/value pair, you also must specify a category, where the categories are aircraft, ships, vehicles, and weapons.
The ammunition, weapons, and equipment defined in AggregateLevel.sms are represen- tative of the weapons and equipment in common use by the United States and Russia. However, you can add any sort of resource you want. For example, you could create entries for knives, sling shots, and shovels. These could be added to assemblies or directly to a simulation object. The only real requirement for making them useful in a scenario is to assign an appropriate level of combat strength when you add them to a simulation object.
To define an ammunition, equipment, or weapon item:
Choose Edit Ammunition and Equipment. The Edit Ammunition and Equipment dialog box opens (Figure 67-5).
Select the tab for the type of resource you want to add.
Click the Add button ( ). A row is added to the list. The Key cell is editable.
Type the key value.
Click Tab or double-click the Display Name cell to make it editable.
Type the text you want to be visible in the lists where this item will be included.
For ammunition items, select an option in the Type list. For equipment items, select the appropriate category. For weapon items, select Weapon Category.
Click OK.
A unit does not model individual entities. It represents some number of vehicles and personnel. For example, a mechanized infantry company has personnel, armored personnel carriers, and so on, which carry a variety of weapons and ammunition.
Rather than explicitly configuring a unit to have, for example, 20 APCs, 20,000 rounds of ammunition, 10 howitzers, and 200 infantry, you can configure the ammunition and weapons for one APC as an assembly. Then you would assign a unit 20 APC assem- blies. You would not have to tally all the resources associated with an APC.
This becomes even more beneficial if more than one unit uses an assembly. For example, the Scout Hvy PLT US unit uses M3A3 assemblies. The Tank CO US uses M1A2 assemblies. The AR CAV TRP US uses M1A2s, M3A3s, and M1064 assem- blies. While it might be a manageable process to configure M1A2s just for one unit and M3A3s just for one unit, to use them in multiple units and have to calculate the sum of all of their weapons and ammunition each time would become tedious and error-prone. Using assemblies makes it easy to assign multiple units of each type to a unit.
When you create an assembly, you specify the equipment, weapons, ammunition, vari- ables, and systems that get configured for a simulation object when you add the assembly to it.
To create an assembly:
Choose Edit Assemblies. The Edit Assemblies dialog box opens (Figure 67-6).
Figure 67-6. Edit Assemblies dialog box
Click the Add button ( ). The New Assembly dialog box opens.
Type a name for the assembly.
Optionally, select an assembly to base the new one on.
Click OK. The new assembly is added to the Assembly list.
Edit the assembly.
An assembly specifies equipment, weapons, ammunition, variables, and systems. Vari- ables represent entity resources that do not fit into weapons, ammunition and equip- ment. These include tangible resources, such as fuel, water, and personnel, and intangible variables, such as health and combat power. If you do not specify particular variables for an assembly, you can specify them directly for a simulation object.
!
!
If you specify variables for an assembly, when you roll up assemblies, the variables in the assembly overwrite the values that have been set directly. Therefore, it is recommended that you use them consistently in all your assemblies and that you not edit these values directly in a unit if you know that you will use assemblies that might overwrite them.
To edit an assembly:
Choose Edit Assemblies. The Edit Assemblies dialog box opens (Figure 67-6).
In the Assembly list, select the assembly that you want to edit.
For the Equipment, Weapons, Ammunition, and Variables tabs, do the following:
Click the Add Attribute button ( ). A new row is added to the list of resources on the tab. In the Element column, it lists the first resource in the list of avail- able resources.
In the Element list, select the resource you want to add to this assembly.
Double-click the Value cell to make it editable.
Type the amount of this resource that you want to be in this assembly.
For the Systems tab, add a system as described in step 3. There is no Value column to complete, but you can edit the system’s properties. To edit properties:
Click the Edit Properties button 
). A Properties dialog box opens.
Set the property values as desired.
Click OK.
To add an assembly to a unit:
Select the entity in the object list.
Click the Add button ( ) above the Assemblies list (Figure 67-7). A new row is added to the list.
In the Assembly column, select an assembly from the list.
Double-click the Amount value to make it editable.
Enter how many of this assembly that you want to add.
In the Assemblies list, select the index number or any cell in the assembly you want to remove.
Click the Delete button ( ).
Editing Aggregate-Level Objects — Creating Roll Up Rules
Sum. Add up the values for all the assemblies.
Average. Use the average value for identical variables in the assemblies.
Maximum. Use the highest value specified for identical variables in the assemblies.
Minimum. Use the lowest value specified for identical variables in the assemblies.
Ammunition, weapons, equipment, and systems are all rolled up by summation. There are no user-editable roll up rules for these resources.
To create roll up rules:
Choose Edit Roll Up Rules. The Edit Roll Up Rules dialog box opens (Figure 67-8).
Figure 67-8. Edit Roll Up Rules dialog box
Click the Add button ( ). A new row is added to the list.
Select the type of roll up item from the list.
Specify a Display Name.
Specify a default value.
Select an option in the Roll Up Rule list.
Editing Aggregate-Level Objects — Rolling Up Assemblies
If you are adding an Average roll up type rule, select an option in the Weight list. This creates a weighted average based on the item you want to give greater weight, such as health or vulnerability.
Add additional items as desired.
Click OK.
!
!
When you roll up assemblies, the resources and modifiers in the assemblies overwrite the current values for the unit. If you have edited any of these resources or modifiers manually, your changes are lost. Any parameters that are not part of an assembly or roll up rules do not change.
To roll up assemblies for a unit:
Select the unit.
Choose Edit Roll Up All, or in the Assemblies area of the Simulation Object Editor window, click Roll Up. You are prompted to confirm the command.
Click Yes.
Editing Aggregate-Level Objects — Adding Activities
You can assign simulation objects an activity. The Simulation Object Editor lets you add activities. When you add an activity, it is included in the list of activities for the Activity set data request. However, unless you add code or a Lua script that takes advan- tage of the new activity setting, assigning an activity to a simulation object will have no effect.
To add an activity to the Activities list:
Choose Edit Activities. The Edit Activities dialog box opens (Figure 67-9).
Figure 67-9. Edit Activities dialog box
Select an object type in the Entity Type list, or click the Add button ( ) to add a new type.
Click the Add Attribute button ( ). A new entry is added to the list of activities. The Key cell is active for editing.
Type a key value for the activity. This is the value that the code or Lua script uses to identify the activity.
Press Tab or double-click in the Display Name cell to make it editable.
Type the text to display in the Activities dialog box.
Click OK.
The aggregate warfare model is data driven. It relies on the comparative strengths of opponents given their resources and movement posture. The data used is from an extensive set of parameters that are configured for each simulation object in the Simula- tion Object Editor.
Most parameters are in one of the following categories:
Real-world absolute values, such as liters of diesel fuel, number of personnel, and amount of equipment and ammunition.
Systems. Movement system, sensor systems, other systems.
Abstract values. Health and strength are abstract values. They represent the relative ability of simulation objects to damage other simulation objects and absorb damage.
For the simulation objects in AggregateLevel.sms provided with VR-Forces, real-world values are based on publicly available information about the types of simulation objects. The various modifiers applied to simulation object behavior are derived from customer requirements for the aggregate warfare model. Modifier values have been set from experimentation to provide what we believe to be realistic results. Values for health and strength have also been developed on a relative scale to obtain reasonable results.
If you add new simulation objects to AggregateLevel.sms, it is important that you try to set health and strength to values that fit with the existing simulation objects. If you create an entirely new SMS for aggregate-level scenarios, you are responsible for devel- oping your own consistent way to represent the relative strengths of the simulation objects.
Parameters are organized in a set of tabbed pages. The following sections describe the parameters on each tab. The Additional Systems tab does not include aggregate warfare parameters. It lets you specify systems that did not logically belong on the other tabs.
Physical parameters describe a simulation object’s footprint and how it faces the external world for each posture, which is a simulation object’s overall mode of interac- tion with its environment.
Parameter Description
Parameter Description
Table 67-1: Physical parameters
Health A quantification of the overall health of the entity. Physical Footprint The area notionally occupied by the simulation object.
The footprint can vary for different postures based on the Footprint Modifier.
Footprint Modifier The amount by which the footprint changes for the indi-
cated posture.
Front Sector Size The number of degrees, centered on the heading, within
which forward-facing sensors and interactions take place.
Rear Sector Size The number of degrees, centered on the heading -180o,
within which rear-facing sensors and interactions take place.
Flank Sector Size The number of degrees, centered on the heading +/-
90o, within which side-facing sensors and interactions take place.
A unit has a movement system. You can specify the movement system on this tab and edit its parameters. You can also specify posture transition times.
Movement can be affected by:
Environmental factors. These properties are specified per movement system.
Posture. A simulation object’s posture can affect its speed.
MOPP level transition time. The amount of time it takes for a unit to change from MOPP level 0 to one of the other MOPP levels.
The Movement tab also has settings for embarkation. These settings are the same as for simulation objects in an entity-level scenario. For details, please see “Configuring Embarkation,” on page 65-34.
Table 67-2 describes the movement parameters.
Table 67-2: Movement parameters
Parameter Description
Parameter Description
Max Speed Modifier When Overlapping Another Unit
Max Speed Modifier (Posture)
The amount to modify a simulation object’s maximum speed when its footprint overlaps another simulation object’s footprint.
The amount to modify the maximum speed based on the posture.
Health Percent For Rout The amount to modify health when in the rout
posture.
Transition Time from Level 0 The amount of time it takes to transition from MOPP
Level 0 to a higher MOPP level.
Max Speed Modifier (MOPP Level)
The amount to modify the maximum speed based on the MOPP Level.
Table 67-3 describes movement system properties. Systems do not all have the same properties.
Table 67-3: Movement system properties
Property Description
Property Description
Rain Modifier by Intensity The amount speed is affected by the intensity of rain.
The lower the modifier value, the more slowly the simulation object moves as rain intensity increases.
Snow Modifier by Intensity The amount speed is affected by the intensity of snow.
The lower the modifier value, the more slowly the simulation object moves as snow intensity increases.
Visibility Degrades Max Speed When Below
Maximum Amount Visibility Can Degrade Speed
Wind Degrades Max Speed When Above
If visibility drops below this value, maximum speed is reduced.
The maximum amount that speed decreases as visi- bility decreases. Higher values decrease speed more.
If wind speed exceeds this value, the maximum speed of the entity is reduced. (Aircraft only.)
Wind Degrades Until Degrade speed due to wind until the wind speed
reaches this value. Then degrade speed at the maximum rate. (Aircraft only.)
Maximum Amount Wind Can Degrade Speed
Retrograde Movement Penalty
The maximum amount that wind can degrade speed. (Aircraft only.)
Speed is reduced by this amount when moving in retro- grade. (Ground movement only.)
To edit movement system properties:
Click the Edit Properties button 
). The Edit Properties dialog box opens.
Edit the values for the various properties.
Click OK.
To edit posture transition times:
Select the Movement tab.
Click Edit Transition Times. The Edit Transition Times dialog box opens (Figure 67-10).
Change the times, in minutes, as desired. Changes take effect immediately.
Click Done.
The Sensors tab lets you specify the sensors that a simulation object has. You can add and remove sensor systems and set their properties using the standard Simulation Object Editor procedures. (For details, please see “Editing a Simulation Object’s Systems,” on page 65-28.)
You can specify the simulation object’s sensor signatures by choosing from a preconfig- ured set of signatures or by defining a custom set. The Sensor Signatures parameters specify the distance at which other simulation objects can sense the simulation object you are editing using the different types of sensors. The preconfigured signatures make it easy to consistently apply the same set of signatures to similar object types.
As with movement, a unit’s posture and MOPP level affect its ability to use its sensors. You can specify signature modifiers for each posture and MOPP Level.
Simulation objects have combat power in five domains: Anti-Air, Anti-Tank, High Explosive, Anti-Personnel, and Anti-Ship. The Attack tab specifies the parameters that determine a unit’s ability to attack an opponent in these domains. It also lets you add weapon systems to the simulation object.
Table 67-4: Attack parameters
Parameter Description
Parameter Description
Range The distance at which a simulation object can attack in each domain.
Hit Factor When compared to the defense factor for a target simulation object, determines the probability of the attack hitting the target.
Strength The simulation object’s strength in each type of combat. This is an abstract value.
Ammunition Usage The number of rounds per minute used for each type
of combat. This value is apportioned among ammuni- tion of the same type. For example if the ammunition usage for Anti-Personnel combat is 1000 rounds per minute and a simulation object has 12.7mm ammuni- tion and 7.62mm ammunition, both of which are type Anti-Personnel, then the simulation object uses 500 rounds per minute of each type of ammunition.
Ammunition Auto-Resupply Rate
The amount of ammunition that is automatically resupplied each day if auto-resupply is enabled for this simulation object.
Ammunition The types of ammunition this simulation object has, the amount of each type, and whether or not pacing or tracking is enabled.
Distribution The proportion of casualty types from an attack.
Sector Combat Power Modi- fiers
Posture Combat Power Modi- fiers
The amount the base combat power is modified depending on which sector is being attacked.
The effect on combat power of each posture.
Combat Range Modifiers The effect on the range at which a simulation object
can attack based on its posture.
CID Level Combat Power Modifiers
MOPP Level Combat Power Modifiers
The effect on combat power of the enemy detection and classification level.
The effect on combat power of the MOPP Level.
If Morale is Less Than A percentage of morale below which combat power is
affected.
Adjust Combat Power By The combat power modifier to apply if morale is less
than the specified amount.
Table 67-4: Attack parameters
Parameter Description
Parameter Description
Environmental Conditions Combat Power Modifier
Weapon System Auto- Resupply Rate
The combat power modifier to apply if precipitation intensity is at its maximum or if there is no illumina- tion.
The number of rounds per day supplied to each weapon system if auto-resupply is enabled.
Table 67-5: Defense parameters
Parameter Description
Parameter Description
Vulnerability The amount that a simulation object is vulnerable to the different types of attack.
Defense Factor for Guided Munitions
The ability to defend against guided munitions.
NBC Vulnerability Vulnerability to nuclear, biological, or chemical contamination.
Posture Vulnerability Modi- fier
The effect of different postures on the simulation object’s ability to defend itself.
Sector Vulnerability Modifier The ability of the simulation object to defend itself to
the front, rear, and flanks.
MOPP Level Vulnerability Modifier
The ability of the simulation object to defend against NBC contamination at different MOPP Levels.
Table 67-6: Personnel and Equipment parameters
Parameter Description
Parameter Description
Personnel Officers Number of officers.
Personnel WOs Number of warrant officers.
Personnel NCOs Number of non-commissioned officers.
Personnel Enlisted Number of enlisted persons.
Equipment List of equipment types, the number of each, and whether it is flagged for pacing, tracking, or none.
Weapons List of weapon types, the number of each, and whether it is flagged for pacing, tracking, or none.
Food.
Water.
Oil.
Lubricant.
Motor gas.
Aviation fuel.
Diesel fuel.
Other Supplies. You can add any other type of supply that you want. The list of items in the Supply drop-down list is drawn from ./data/simulationModelSets/Aggre- gateLevel/gui/rwKeywordValuePairs.xml. (For information about this file, please see “Editing Reader/Writer Key/Value Pairs,” on page 67-26.) You can type in any other supply type that you want to.
The supplies added here are only used by engineering objects. To use a supply, you configure it here and in the engineering object. For example, a combat engineering company has other supplies called Construction-Material and Explosives.
This tab also lets you specify the conditions under which a simulation object can receive supplies.
Editing Aggregate-Level Objects — Configuring Combat Engineering Objects
Combat engineering objects (CEOs) can affect mobility of simulation objects and can cause attrition. Therefore, their simulation models include the information needed for these effects. Since CEOs can be constructed by units, their models include parameters that specify the types of materials needed to create them and sizing information.
The actual process of configuring CEOs is similar to that of other objects. Table 67-7 describes the parameters specific to CEOs. Some parameters do not apply to all CEOs.
Table 67-7: Combat engineering object parameters
Parameter Description
Parameter Description
Short Name The name displayed on the map and sent as marking text over the network.
Height The height of the object.
Maximum length Maximum length of single constructed objects. If a
longer object is specified, it is created as several objects.
Width The width of a line object.
Minimum Completion Percentage for Effect
Minimum Completion Percentage to Detect
The minimum completion percentage before the object affects simulation objects.
The minimum completion percentage before simula- tion objects can detect the object.
Attrition The rate of attrition to an affected simulation object in each domain.
Mobility Modifiers The amount that mobility of an affected simulation
object is modified in each type of movement.
Vulnerability Modifiers The amount that an affected simulation object’s
vulnerability is modified in each domain.
Signature Modifiers For object types that can be affected by this object,
the amount that each type of sensor signature is affected.
Resource Required The type of resource needed to construct this
object.
Resource Amount The amount of the required resource needed to build
this object.
Editing Aggregate-Level Objects — Editing Reader/Writer Key/Value Pairs
Table 67-7: Combat engineering object parameters
Parameter Description
Parameter Description
Is Concealed If selected, the object is detected based on a random probability in the detecting sensor. If cleared, the object is always detected by the appro- priate sensor.
Maximum Relative Size For areal objects, the maximum size of a simulation
object, relative to the object, for it to be affected by the object. For example, if the maximum relative size for a fortified area is .75, a simulation object must be 75% of the size of the area or smaller for it to be protected.
Some display text is not automatically included in the untranslated.ts file provided with VR-Forces. The Simulation Object Editor lets you map some internal keywords to display text so that you can translate it. These internal keywords are called reader/writer keys and they are managed using key/value pairs. These mappings are stored in
./data/simulationModelSets/AggregateLevel/gui/rwKeywordValuePairs.xml. If you edit this
file, do not change the paramName; change the string mapped to it.
Besides allowing for translation, you can add new entries to this file. Table 67-8 describes the effect of adding new keyword:value pairs.
Table 67-8: Effect of editing rwKeywordValuePairs.xml parameters
Parameter Result
Parameter Result
Type Added to the Type list for the Edit Ammunition and Equipment dialog box, Ammunition tab, in the Simulation Object Editor.
Category Added to the Category list for the Edit Ammunition and Equip- ment dialog box, Weapon tab and Equipment tab, in the Simula- tion Object Editor.
Posture Added to the list of Postures in the Posture set data request. However, selecting such a posture would not have any effect unless complementary code is written to update the simulation engine.
Resource-Item Added to the Supply list for configuring Other Supplies on the Supplies tab for simulation objects in the Simulation Object Editor.
68. Adding DI-Guy Models to VR-Forces
This chapter explains how to take DI-Guy models created with the DI-Guy SDK and integrate them into VR-Forces.
Adding New DI-Guy Models to VR-Forces 68-2
Copy DI-Guy Files to the Data Directory 68-2
DI-Guy Configuration Files 68-3
Adding a New DI-Guy Animation 68-4
How VR-Forces Maps DI-Guy Models 68-5
Add a New DI-Guy Entity in the Simulation Object Editor 68-5
Adding DI-Guy Models to VR-Forces — Adding New DI-Guy Models to VR-Forces
VR-Forces supports DI-Guy characters and includes many lifeform characters. However, MAK customers sometimes want to add their own DI-Guy characters. The general process for adding a new character is as follows:
Create the new character using DI-Guy software and copy the required files to the
./data directory.
Add a model definition and element definition for the new character.
If the character has animations, add them to character_animations_table.mtl.
Create a new VR-Forces character in the Simulation Object Editor.
VR-Forces stores files for DI-Guy characters in ./data/Lifeforms/DIGuy and its subdirec- tories. After you create a new character using DI-Guy software, you must copy the files for this character to these directories.
DI-Guy documentation recommends that all customer content be placed in
$(DIGUY)/custom. To follow this convention, create a directory called ./data/Life- forms/DIGuy/custom and put your files in the appropriate subdirectories under it.
VR-Forces can visualize custom DI-Guy characters based on DIS enumerations mapped to element definitions or by recognizing custom DI-Guy PDUs.
If you want to map your custom characters to element definitions, then you must add new simulation models in the Simulation Model Editor. This will automatically create the complementary model and element definitions and object type mappings.
If you want to visualize characters based on custom DI-Guy PDUs without creating element definitions or object type mappings, place the DI-Guy files in the
./data/Lifeforms/DIGuy/custom directory as described in the previous paragraph. No
further configuration is needed.
Adding DI-Guy Models to VR-Forces — DI-Guy Configuration Files
VR-Forces can specify the character, appearance, and animation values for DI-Guy models used in 3D visualization applications such as VR-Forces and VR-Vantage. A model’s character determines the kinds of movement it can make. The appearance determines what it looks like. The animation specifies the movements that the character makes.
In the VR-Forces front-end, you can specify the animation with the DI-Guy Animation task. You can set the appearance with the DI-Guy Appearance set data request. For details about specifying DI-Guy characteristics in the front-end, please see “DI-Guy Animation,” on page 29-5, “DI-Guy Characteristics (Appearance, Head, Body Weight),” on page 34-16, and “DI-Guy Hand Item,” on page 34-16.
You can specify the default character, appearance, and animation for a lifeform entity in the Simulation Object Editor. (For details, please see “DI-Guy Animation,” on
page 29-5“Editing a Lifeform’s Visual Model and Animation,” on page 65-16.) The DI-Guy mappings are stored in the entity’s .entity file.
The DI-Guy animations available to lifeforms are controlled by
./appData/settings/vrfSim/character_animations_table.mtl. This information is used to populate the lists in the Simulation Object Editor. You can edit this file to add addi- tional DI-Guy characters to those already configured for VR-Forces. The syntax of entries is described in the file.
!
!
Any characters you add to character_animations_table.mtl must be valid DI- Guy characters. You cannot arbitrarily make up new types of characters. If you create new characters using a supported version of the DI-Guy SDK, VR-Forces will support these characters.
Adding DI-Guy Models to VR-Forces — DI-Guy Configuration Files
This section explains how to add a new DI-Guy animation to VR-Forces. It assumes that you have the DI-Guy software and have created the new animation.
The new animation must be made with the same version of DI-Guy supported by VR-Forces. Please see VR-Forces Release Notes for the currently supported version.
To add a new DI-Guy animation:
Create the new animation in DI-Guy. You will create an animation and add it to a character’s action table. Make sure that the name of the animation file matches the name of the action you added to the action table. For example, if the name of the animation is layEgg, but you call the action lay_egg, it will not work.
There is a 1-1 relationship between characters and their action tables. You cannot use an animation based on a chicken character in a cow character’s action table.
Add the motion_name.bdm file for the animation to ./data/Life- forms/DIGuy/motions.
Add the action_table.cfg file to ./data/Lifeforms/DIGuy/config/diguy.
Add the new animation to ./appData/settings/vrfSim/character_animations_table.mtl. This table determines whether an animation can be assigned to a character using the DI-Guy Animation task (is-taskable-animation True) or whether it is used based on the entity’s behavior. For example, if a character is moving faster than a certain speed, it is given a running animation. An entry for our lay egg example would look like the following:
(chicken
(display-name "Chicken") (animations
(animation
(animation-name "lay_egg")
(name-to-be-displayed "Lay an egg") (is-taskable-animation True) (animation-variant "normal")
)
(animation
(animation-name "feeding") (name-to-be-displayed "Feed") (is-taskable-animation True) (animation-variant "normal")
)
...
Adding DI-Guy Models to VR-Forces — Add a New DI-Guy Entity in the Simulation Object Editor
Add a new entity in the Simulation Object Editor, as described in “Creating a New Simulation Object,” on page 65-32.
When you specify the 3D model, the list of character names is drawn from the display- name attribute in the entries in ./appData/settings/vrfSim/character_animations_table.mtl. Therefore, it must have been updated before you can specify the 3D model in the Simulation Object Editor.
Adding DI-Guy Models to VR-Forces — Add a New DI-Guy Entity in the Simulation Object Editor
69. The Object Parameter Database
This chapter provides a detailed description of the object parameter database. It will be most useful to VR-Forces users who need to develop and configure new components.
The Object Parameter Database 69-2
VR-Forces Classes and Object Parameters 69-3
Local and Remote Subcomponents 69-9
Component Descriptors and Parameters 69-13
Common Elements of Component Descriptors 69-13
Configuring the Priority of Components 69-16
Creating a System Definition File 69-17
Configuring System Connections 69-18
Adding Variable Bindings to Platform and System Files 69-21
Adding a Variable Binding 69-22
Making Variables Editable in the Simulation Object Editor 69-23
Adding Platform Variable Bindings to the Simulation Object Editor . 69-23 Adding System Definition File Variables to the Simulation Object Editor ... 69-25
Configuring Tactical Graphics 69-26
Pathname Interpretation in Simulation Model Set Files 69-26
Updating Object Parameter Database Files for New Releases 69-27
!
!
Before you make any changes to the object parameter database, make a backup copy of the file you are changing.
Figure 69-1 illustrates the organization of an entry in the OPD. The primary definition of a simulated object, such as an entity, a tactical graphic, or a cultural feature, is stored in a file with the extension .entity. The .entity file specifies the object type enumeration, marking text, organizational information, and other parameters. It references a plat- form file (extension .ope), that provides a set of generic components for the object type, such as ground platform, surface platform, or line object. Each .entity file also specifies the systems that allow it to interact with the simulated environment, such as sensors, weapons, and movement systems.
Systems are configured in system definition files. System definition files group related component and connection specifications into convenient packages. The components reference additional configuration files. The system definition files also make it possible to add systems to simulation objects in the Simulation Object Editor.
weapons system (.sysdef)
weapons system (.sysdef)
weapons system (.sysdef)
weapons system (.sysdef)
movement system (.sysdef)
movement system (.sysdef)
Platform (.ope) Object (.entity)
weapons system (.sysdef)
weapons system (.sysdef)
weapons system (.sysdef)
weapons system (.sysdef)
damage system (.sysdef)
damage system (.sysdef)
weapon system (.sysdef)
sensor system (.sysdef)
ammo select
(.asl)
hit
(.hit)
damage
(.dmg)
detection
(.csv)
formation
(.frm)
ammo select
(.asl)
hit
(.hit)
damage
(.dmg)
detection
(.csv)
formation
(.frm)
signature rules (.mtl)
weapons system (.sysdef)
weapons system (.sysdef)
weapons system (.sysdef)
weapons system (.sysdef)
other systems (.sysdef)
Figure 69-1. Object definition
When you create any simulated object in VR-Forces, an instance of DtVrfObject is created in the simulation engine. Different types of simulation objects require different parameters for simulation and publishing, which are initialized by a subclass of DtVrf- ObjectParameters, and stored in a subclass of DtVrfObjectBaseStateRepository. Each DtVrfObject “has a” DtVrfObjectParameters and a DtVrfObjectBaseStateRepository. The type of parameters object to use for simulation object creation is specified in the simula- tion object's platform file by the parameter-type parameter. The state repository is speci- fied in the state-repository parameter in the local-objects block. For example, when an entity that references the platform Ground_Vehicle.ope, which has a parameter type ground-vehicle-param, is created, a DtVrfGroundVehicleParameters object is created to read in the initial values from, and a DtGroundVehicleStateRepository is used to store runtime values.
This enumeration scheme describes a tree that goes from a more general specification to a more detailed one. Figure 69-2 illustrates a partial object type tree. To build an object type enumeration, start at the Kind and work your way down the tree, adding the number for each element. So, for example, if you follow the tree down to M1A2 you build the enumeration: 1 1 225 1 1 3 0. Since M1A2 is a leaf in the tree, the last field is
For more information about the object enumeration scheme, please see the SISO Enumerations Document (SISO Reference for Enumerations for Simulation Interoperability).
(Root)
Kind = platform (1) Kind = munition (2)
Domain = land (1) Domain = air (2) Domain = antiarmor (2) Country = US (225)
Category = Tank (1) Subcategory = M1Abrams (1) Specific = M1A2 (3)
Extra = M1A2 (0)
Figure 69-2. Object type enumeration tree
VR-Forces adds a field to the standard 7-digit entity enumeration so that we can manage objects that are not part of the DIS/RPR FOM enumeration scheme, such as units and tactical graphics. We enclose the seven-digit enumeration in parentheses and preface it with the object super-type (Figure 69-3). For example, the object enumera- tion for an M1A2, described in the previous paragraph, becomes the object type: 1 (1 1 225 1 1 3 0).
(object-type 1 (1 1 225 1 1 3 0))
object super-type DIS/RPR FOM enumeration Figure 69-3. VR-Forces object-type parameter
Table 69-1 lists the values VR-Forces can use for the object super-type. For more infor- mation, please see objTypeEnums.h or “Object Type Enumerations,” on page C-9.
Table 69-1: Object super-type field values
Object super-type Meaning
Object super-type Meaning
Other.
Individual (platform entities, individual tactical graphics).
Unit.
Disaggregated unit (a unit composed of other simulation objects).
Aggregated unit (a unit that does not have subordinate simulation objects).
Each simulation object in the OPD has two object types – the published object type and the matching object type.
The published object type is used as follows:
When the front-end sends a create simulation object message to the back-end, the back-end uses the object type to determine which model to create.
When the back-end publishes a simulation object on the network it uses the published object type as the object enumeration.
Each field of a published object type must have a specific value. The matching object type is used as follows:
When the back-end receives a request to create a simulation object and it cannot find an exact match for the object type that it is sent, it finds the best match among matching object types to determine which model to create. (For details about the best match method, please see “The Best Match Method,” on page 69-7.)
When the back-end discovers a simulation object on the network, it finds the best match among matching object types so that it can create local representative DtVrf- Objects.
The matching type can be the same as the published object type or it can have wild- cards (-1).
For example, in VR-Forces, the published object type for an A-10 Thunderbolt is 1:2:225:2:4:1:0. If the matching type for the A-10 Thunderbolt is also 1:2:225:2:4:1:0 and VR-Forces discovers a remote simulation object with that same object type, it can match it to the A-10 Thunderbolt simulation model and can represent it properly in the simulation. However, if VR-Forces discovers a remote simulation object with the object type 1:2:225:2:4:1:1 (which is just a variation of an A-10), it will not be able to match the remote entity to an A-10 model because there is no A-10 match for that object type. (VR-Forces would end up matching the remote entity to a more generic fighter model, as explained in “The Best Match Method,” on page 69-7.) But if the A- 10’s matching object type is 1:2:225:2:4:1:-1, then VR-Forces will be able to match the remote entity to the A-10 model using the best match method.
Object types are specified in the .entity file as follows:
<simObject objectType="1:1:2:225:2:4:1:0" matchType="1:1:2:225:2:4:1:-1" platform="@(platforms-dir)/Fixed_Wing_Aircraft.ope">
The objectType attribute specifies the published object type; matchType specifies the matching object type.
As explained in “Object Types,” on page 69-4, object types describe a simulation object in increasing specificity as the object type fields move from left to right. Objects in the object parameter database are specified in a hierarchy in which entries at higher levels of the hierarchy have wildcard values (-1s) in object type fields that do not need to be specified at that level of the hierarchy. When VR-Forces looks up an object type, it begins at the root of the tree, working its way down until no better matches are found (the best match method.)
Suppose the object type hierarchy for fighter jets looks like this:
-1:-1:-1:-1:-1:-1:-1:-1 – match any object.
1:1:2:-1:-1:-1:-1:-1 – match any fixed-wing entity.
1:1:2:225:2:-1:-1:-1 – match any U.S. attack fixed-wing.
1:1:1:2:225:2:4:1:-1 – match any A-10 Thunderbolt. (In VR-Forces, this is the A10 Thunderbolt matching object type.)
1:1:1:2:225:2:4:1:0 – match a specific A-10 Thunderbolt. (In VR-Forces, this is the A10 Thunderbolt published object type.)
As you replace each wildcard value (-1) with a specific enumeration, the scope of the object type narrows. Given this hierarchy, if VR-Forces discovers a simulation object with the object type 1:1:2:225:2:11:0:0, it starts trying to find the best match as follows:
The discovered object type matches the top level - any object, because all fields are wild cards.
The discovered object type matches the fixed-wing object type, because the first three fields match and the rest are wild cards.
The discovered object type matches the U.S. attack fixed-wing object type.
The discovered object type does not match the A-10 Thunderbolt matching object type. Although the first five fields match, the sixth is different and is not wild carded.
The best match is the U.S. attack fixed-wing object type, so VR-Forces will use the generic U.S. attack fixed-wing model to represent the discovered simulation object.
In addition to specifying an object-type for each object, you must specify a parameter-type for each object. The parameter-type determines the parameters and components that can be specified for an object. For example, a rotary-wing or fixed-wing entity can have a nose-support parameter, but a ground vehicle cannot. Figure 69-4 illustrates the object parameter type hierarchy.
vrf-base-object-param
vrf-object-param moving-object-param
aggregate-object-param cultural-feature-param fixed-wing-entity-param ground-vehicle-param human-param
missile-param
rotary-wing-entity-param subsurface-entity-param surface-entity-param bomb-param
global-environment-param circle-object-param
point-object-param
scripted-movement-object-param tactical-smoke-param
Figure 69-4. Object parameter hierarchy
The parameter-type specifies the set of parameters appropriate to a simulation object, and the object state repository maintains state information for a simulation object, so the parameter-type and state repository must match. For more information, please see “The State Repository Hierarchy,” on page 69-12.
The object-type is specified in an object’s .entity file. The parameter-type is specified in the platform (.ope) file.
As explained in “Local Objects and Remote Objects,” on page 3-9, each VR-Forces back-end simulates objects itself (local objects), and maintains state information about remote objects. All of these objects are instantiated as DtVrfObjects. The DtVrfObject class has a “has a” relationship with the following classes:
DtSimComponentManager
DtVrfObjectPlanManager.
These classes are referred to as subcomponents of the object. Table 69-2 maps the subcomponent classes to the parameters that specify them.
Table 69-2: Subcomponent classes and parameters
DtSimObjectStateRepository state-repository
DtSimObjectNetInterface net-interface
DtOrganizationManager organization-manager
DtSimTaskManager task-manager DtSimComponentManager component-manager DtVrfObjectPlanManager plan-manager
VR-Forces creates different subcomponents for an object depending on whether it is a local object or a remote object. The subcomponents are specified in the local-objects and remote-objects parameter blocks for that object. Table 69-3 lists the permissible entries for each parameter listed in Table 69-2.
Table 69-3: Permissible subcomponent parameters
state-repository vrf-object-base-state-repository
vrf-overlay-object-state-repository
vrf-object-state-repository
vrf-moving-object-state-repository
vrf-aggregate-state-repository
fixed-wing-entity-state-repository
ground-entity-state-repository
human-state-repository
cultural-feature-state-repository
missile-entity-state-repository
rotary-wing-entity-state-repository
surface-entity-state-repository
subsurface-entity-state-repository net-interface aggregate-local-entity-net-interface
individual-local-entity-net-interface
local-environmental-net-interface
pseudo-aggregate-local-entity-net-interface
vrf-aggregate-remote-entity-net-interface
vrf-individual-remote-entity-net-interface
vrf-remote-environmental-net-interface
aggregate-remote-entity-net-interface
individual-remote-entity-net-interface
remote-environmental-net-interface
task-manager local-task-manager
component-manager component-manager plan-manager vrfobject-plan-manager
Every object must have a state repository specified. Objects that should be published need a net interface. Other subcomponents are optional. However, for most simulation objects, you will want to specify a task manager, plan manager, and component manager so that you can control the simulation object and give it tasks.
The local and remote objects parameters are specified in the platform (.ope) files. There- fore they apply to all simulation objects that reference a particular platform. Use the existing entries in the object parameter database as guidance if you create a new plat- form or change an existing platform. A typical entry for local and remote objects is:
(local-objects
(state-repository "ground-entity-state-repository") (state-repository-min-tick-period -1.000000)
(state-repository-min-tick-period-variance -1.000000) (net-interface "individual-local-entity-net-interface") (net-interface-min-tick-period -1.000000)
(net-interface-min-tick-period-variance -1.000000) (task-manager "local-task-manager")
(component-manager "component-manager") (plan-manager "vrfobject-plan-manager")
)
(remote-objects
(state-repository "vrf-moving-object-state-repository") (state-repository-min-tick-period -1.000000)
(state-repository-min-tick-period-variance -1.000000)
(net-interface "vrf-individual-remote-entity-net-interface") (net-interface-min-tick-period -1.000000)
(net-interface-min-tick-period-variance -1.000000) (task-manager "")
(component-manager "") (plan-manager "")
)
Each VR-Forces object must have a state repository to maintain essential state informa- tion about the object, such as its current location, orientation, appearance, and so on. Therefore, each object must specify a state repository and the state repository must match the parameter-type for the object. (The state repository and parameter-type are specified in the platform file.)
Table 69-4 lists parameter types and the state repository type required.
Table 69-4: State repository and parameter types
State Repository Type Parameter Type
State Repository Type Parameter Type
ground-entity-state-repository ground-vehicle-param fixed-wing-entity-state-repository fixed-wing-entity-param individual-lifeform-state-repository individual-lifeform-param rotary-wing-entity-state-repository rotary-wing-entity-param human-state-repository human-param
cultural-feature-state-repository cultural-feature-param missile-entity-state-repository missile-param
surface-entity-state-repository surface-entity-param subsurface-entity-state-repository subsurface-entity-param vrf-moving-object-state-repository moving-object-param
vrf-overlay-object-state-repository vrf-object-state-repository
vrf-object-param
VR-Forces manages network relationships of local and remote simulation objects through the network interface classes. Choose the set of local and remote network inter- face types that most closely represent the type of object being simulated. For example, for an individual vehicle such as a tank, choose individual-local-entity-net-interface for the local network interface and vrf-individual-remote-entity for the remote network interface. Please see Appendix C, Object Parameters for tables that list the network inter- faces used for the simulation objects provided with VR-Forces.
The parameters for a simulation object include a list of all the sensor, controller, and actuator components it uses. (For details, please see “VR-Forces Uses a Component Architecture,” on page 15-8.) These components might be in the OPE file or in a system definition file. If there are no components of a certain type (for example, no sensors), you can omit the list. (In other words, you do not need a placeholder list for unused components.)
A component descriptor is a text block in a platform or system definition file that describes a component (see Example 69.1). A component descriptor must include the type of the descriptor and the type of the component that it is describing. A component descriptor can also contain parameters for the component. “Common Elements of Component Descriptors,” on page 69-13 describes the construction of a component descriptor.
A component can create a port group, which groups a set of related ports together. For example, the automotive-control port group groups the throttle, steering, and brake ports. Use of port groups simplifies specification of connections because you just have to specify a port group instead of many individual ports. For component descriptions and a list of port groups, please see the online help for the OPD Editor. For a detailed discussion of ports and port groups, please see API documentation.
The port group also provides a mechanism for ensuring that only one data provider attempts to put values on those ports each simulation frame. For more information, please see “Configuring the Priority of Components,” on page 69-16.
The common elements of component descriptors are:
Name – The first element in a component descriptor specifies the component’s name. This name can be whatever you want, but it must be unique within the simulation object or the system the component is defined in. It gets used in the connections section of the simulation object’s parameters. Other components may use this name to find the specified component. In Example 69.1, the name of the first component is move-along (line 2).
component-descriptor-type – The component descriptor factory creates the type of component descriptor specified by this type. This lets the system know what types of additional data may be present. In Example 69.1, the component descriptor type for the move-along component is ground-move-to-descriptor (line 3).
component-type – The component factory creates the type of component specified in this entry. In Example 69.1, the component type is ground-auto-move-along- controller (line 4).
The Object Parameter Database — Component Descriptors and Parameters
The component-descriptor-type and component-type values are specified in code. You cannot make them up. Please see compTypes.h and compDescTypes.h.
connections (optional) – The connections (Example 69.1, line 46) entry specifies how the components connect to one another (through ports, port groups, or both). Components attach to each other by connecting output and input ports to one another, or output port groups to input port groups. Since a component can have more than one port, port group, or both, the name of the port or port group to use is also specified. If a simulation object does not have any components that need to connect to one another, then you can omit this entry. Items in the connections entry can be in one of the following forms:
Specify a port-to-port connection:
connect component_name:output_port component_name:input_port
Specify a port group-to-port group connection:
connect component_name:output_port_group component_name:input_port_group
The connections in Example 69.1 use this format.
Specify a port-to-port connection, in which one or both of the ports exists inside of a group, as follows:
The input port belongs to an input port group:
connect component_name:output_port component_name:input_port_group:input_port
The output port belongs to an output port group:
connect component_name:output_port_group:output_port component_name:input_port
Both input and output ports belong to groups:
connect component_name:output_port_group:output_port component_name:input_port_group:input_port
The port and port group names are defined in code for each component. Please see class documentation or the online help for the OPD Editor for the names of port and port groups used by a given component.
The components that you can use are described in the online help for the OPD Editor.
Example 69.1 shows component descriptors for the Move Along and Patrol Between Points controllers and the Powertrain actuator for a ground vehicle (from the ground- tracked.sysdef file.) The Powertrain actuator simulates movement of a ground vehicle based on the throttle, brake, and steering inputs it receives from the automotive controllers. The example also shows how the output port groups for the controllers are connected to the input port group of the powertrain.
(component-type "ground-auto-move-along-controller") 5 (min-tick-period -1.000000)
(min-tick-period-variance -1.000000)
(tick-period-uses-real-time False)
(process-state-repository-name "")
(process-state-repository-type "")
(is-enabled True)
(near-distance 25.000000)
12 (at-distance 1.000000)
(approach-speed 2.000000)
(road-center-offset 2.000000) 15 )
(patrol-between-points
(component-descriptor-type "ground-move-to-descriptor")
(component-type "ground-auto-patrol-between-controller")
(min-tick-period -1.000000)
(min-tick-period-variance -1.000000)
(tick-period-uses-real-time False)
(process-state-repository-name "")
(process-state-repository-type "")
(is-enabled True)
(near-distance 25.000000)
26 (at-distance 1.000000)
(approach-speed 2.000000)
(road-center-offset 2.000000) 29 )
) ;; end controllers
(actuators
(powertrain
(component-descriptor-type "automotive-component-descriptor")
(component-type "automotive-actuator")
(min-tick-period -1.000000)
(min-tick-period-variance -1.000000)
(tick-period-uses-real-time False)
(process-state-repository-name "")
(process-state-repository-type "")
(is-enabled True)
(art-part-list )
(check-terrain-collisions False)
(use-high-fidelity-ground-clamping True) 44 )
(connections
(connect move-along:automotive-control powertrain:automotive- control)
(connect patrol-between-points:automotive-control powertrain:automotive-control)
) ;; end connections
The connection in line 47 would read: the move-along component sends output to its automotive-control output port group. The powertrain receives the move-along controllers output through its automotive-control input port group.
The Object Parameter Database — Platform Files
For example, among the ground movement controllers, the collision avoidance controller is placed on the controller list before any of the other movement controllers. If this controller needs to provide input to the ground automotive actuator to avoid a collision, it takes control of the automotive-control port group on the next tick and overrides the controller that previously owned the port group (such as Move To or Move Along).
Platform files (extension .ope) are the foundational configuration files for all simulated objects. They provide the basic description of each type of simulation object that you can create, such as a ground vehicle, surface vessel, or human. They also define types of tactical graphics. All platform files are part of an SMS. A platform file includes all of the components that every simulation object of that type needs to have, such as collision avoidance, radios, script controllers, and so on.
A platform file does not include systems that vary among specific examples of the plat- form, such as weapon systems, movement systems, and damage systems.
A platform file uses variables for the parameters that need to be different for specific examples of a platform. For example, all ground vehicles have a maximum speed, but tanks and civilian vehicles have a different value for this parameter. The values for these variables get set in the Simulation Object Editor.
You can create and edit platform files in the OPD Editor or using a text editor. The OPD Editor is the recommended way to edit them. Platform files use MTL syntax. Most VR-Forces users will not need to create new platform files. You may need to add components or change parameters to be variables.
The Simulation Object Editor allows VR-Forces users to easily add component systems, such as weapons, sensors, and movement, to simulation objects without needing to understand the components, configuration files, and connections required to make these systems work. These systems are defined in system definition files (.sysdef). System definition files are referenced in a simulation object’s .entity file. They are read by the OPD Editor and can be edited in it.
The metadata explains to the Simulation Object Editor how to present the system to the user and how to integrate it into the entity model.
If you want to create a new system definition file, MAK recommends that you copy an existing file and use it as a template for adding the components that you want to configure into a system. You can use the OPD Editor to do this or a text editor.
The format of a system definition file is as follows:
(system-name (controllers
)
(actuators
)
(connections
)
(resources
)
(meta-data
(system-name "Spot Report Generator")
(system-description "Allows the entity to send spot reports though its radio when its sensors detect other entities in the scenario.")
(allowed-state-repository-types "all") (system-categories "other")
(meta-data-entry-list
)
(parameter-data-list
)
)
)
As you can see, system definition files use MTL syntax. (For information about MTL syntax, please see “MÄK Technologies Lisp (MTL) Files,” on page A-3.) The system- name is an arbitrary name that uniquely identifies the system. The component sections list the various controllers, actuators, sensors, and resources that are needed to build the system. The connections section lists the connections among the components.
!
!
You can call the system whatever you want, but the name must not start with a number.
Within each system definition file, you list the connections among the components in the file. (For general information about connections, please see “Common Elements of Component Descriptors,” on page 69-13.) For systems that are self-contained, for example movement systems, there is no need to connect to components in other systems. However, some systems need to connect to components outside their system. For example, a visual sensor needs a list of object types to detect. This section explains how to make these out-of-system connections.
To understand how system definition files and .entity files are integrated, we will look at:
A componentSystem element in a .entity file.
The related system definition file.
The connection section in the system definition file.
The M1A2, which uses the Ground_Vehicle platform, is configured with a visual sensor (in M1A2_Abrams_MBT.entity) as follows:
1 <simObject objectType="1:1:1:225:1:1:3:0" platform="platforms\Ground_Vehicle.ope">
2 ...
<componentSystem systemName="sensor"
platform="@(system-dir)/sensors/visual-sensor.sysdef">
<bodyPosition paramName="sensor-position" right="0.57" forward="-1.14" up="2.1"/>
<real paramName="max-range">4000</real>
</componentSystem>
The sensor component references the system definition file visual-sensor.sysdef. The parameters specified provide values for the variables in the system definition file. (For more information, please see “Adding Variable Bindings to Platform and System Files,” on page 69-21.)
The system definition file has the following connections:
1 (visual-sensor-system 2 ...
(connect system:object-types-to-detect visual-sensor:object-types-to-detect)
(connect visual-sensor:detected-objects system:detected-objects)
(connect system:sensor-offset visual-sensor:sensor-offset) 7 )
(resources )
(meta-data
(system-name "Visual Sensor")
(system-description "Allows an entity to detect other objects through visible light.")
(allowed-state-repository-types "all")
(system-categories "sensor") 14 ...
15 )
The system definition file defines connections for its components. The first connection in the list (line 4) means that some external component (system) is providing input from its object-types-to-detect port to the visual sensor’s object-types- to-detect port. The second connection specifies that the visual sensor’s detected- objects port sends data to some external component’s detected-objects port. When VR-Forces creates a simulation object, it needs to substitute an actual compo- nent for the generic “system” component specified in the system definition file. It does this by referring to an auto-connection block in the OPE file
The platform file has a set of auto-connection blocks like the following (from Ground_- Vehicle.ope):
(auto-connection
(source-controller "target-selection") (source-port-name "object-types-to-detect") (destination-category "sensor")
(destination-port-name "object-types-to-detect")
)
The auto-connection block in the OPE file is a template that VR-Forces uses to match systems of a specified category to the appropriate controllers. In this example the target-selection controller sends data through its object-types-to- detect port to the object-types-to-detect port of any system that is in the sensor category. Since the visual sensor is in the sensor category, it substitutes the target-selection controller for the generic system in building its connections.
Figure 69-5 illustrates the relationships of the OPE file, .entity file, and system defini- tion files referenced in this section and how connections are made.
The M1A2 entity, which uses the Ground_Vehicle platform, has a visual sensor (callout 1). The visual sensor has several connections. The one illustrated in the figure (2) takes input from an external source’s object-types-to-detect port and sends it to the visual sensor’s object-types-to-detect port (3). In this connection, the external source is represented by system. Before the sensor can actually work, this unspecified system must be determined.
When the entity is created, VR-Forces checks all the auto-connections in the OPE file (4). In this case, there is an auto-connection from the target-select controller’s object-types-to-detect port to the object-types-to-detect port of a component whose destination category is sensor (5). To make this connection, the unspecified sensor must be determined.
VR-Forces matches the destination-category value “sensor” in the OPE file to the system-categories value “sensor” in the system definition file and the connec- tions can now be completed (6).
M1A2_Abrams_MBT.entity <simObject objectType="1:1:1:225:1:1:3:0" platform="platforms\Ground_Vehicle.ope"> <componentSystem systemName="sensor" | ||
platform="@(system-dir)/sensors | /visual-sensor.sysdef | > |
M1A2_Abrams_MBT.entity <simObject objectType="1:1:1:225:1:1:3:0" platform="platforms\Ground_Vehicle.ope"> <componentSystem systemName="sensor" | ||
platform="@(system-dir)/sensors | /visual-sensor.sysdef | > |
1 
"
visual-sensor.sysdef
(connect system:object-types-to-detect
visual-sensor:object-types-to-detect)
(system-categories "sensor")
system | ||
object-types-to-detect | ||
system | ||
object-types-to-detect | ||
visual sensor
object-types-to-detect
Ground_Vehicle.ope
(auto-connection
(source-controller "target-selection")
(source-port-name "object-types-to-detect") 
(destination-category "sensor") (destination-port-name
"object-types-to-detect")
)
sensor | |
object-types-to-detect | |
sensor | |
object-types-to-detect | |
target-selection
5
object-types-to-detect
target-selection | |
object-types-to-detect | |
target-selection | |
object-types-to-detect | |
visual sensor | |
object-types-to-detect | |
visual sensor | |
object-types-to-detect | |
6
Figure 69-5. External component connection
Most VR-Forces users add new systems by copying existing ones and changing their parameters. If you add new systems in this way, you will not need to worry about adding connections, since the existing auto-connection system will handle them automatically. If developers add new types of components that require intersystem connections, they will need to add new auto-connection blocks to the appropriate OPE files for them to connect.
Platform files and most system definition files are used by multiple simulation objects. However, the values of some parameters may need to vary for the different simulation objects that use them. This is handled by using variables in the platform and system definition files and specifying the values for these variables in the .entity files. VR-Forces uses variable bindings for the parameters that you are most likely to want to change from simulation object to simulation object. If there are other parameters that you want to vary, you can add your own variable bindings.
When you add a variable binding, you must:
Change the hard-coded value to a variable in the platform or system definition file.
Add the variable to the .entity file.
Update the Simulation Object Editor so that you can edit the value for the new variable.
The following example shows a variable binding for fuel in a movement system. The variable is specified in the system definition file as follows:
(resources (fuel
(resource-type "real-resource") (amount $fuel-amount)
(full-amount $fuel-amount)
)
)
The .entity file for a simulation object that uses this movement system specifies a value for the variable:
<componentSystem systemName="movement"
platform="@(system-dir)/movement/ground-tracked.sysdef">
<real paramName="fuel-amount">465</real>
</componentSystem>
As you can see, the parameter defined as fuel-amount in the .entity file is referenced as
$fuel-amount in the system definition file.
The procedure for adding a variable binding is the same for platform files and system definition files.
To add a variable binding to a platform file or system definition file:
In the system definition file, substitute a variable name, in the format $variable- name for the hard-coded value that you want to replace. For example, the Ground_- Vehicle.ope file has a value is-organized:
(groundParams
…
(is-organized True)
…
)
To make this a variable, replace the value with a variable name, as follows:
(groundParams
…
(is-organized $entity-is-organized)
…
)
You can do this by hand in the OPE file or in the OPD Editor.
Optionally, specify a default value for the variable. The default value is used if no value is specified for an entity type that uses this OPE file. The syntax for speci- fying a default value is:
(default “value”)
In this example, to set the default value to True, do the following:
(groundParams
…
(is-organized $entity-is-organized (default “True”))
…
)
In each .entity file that uses this platform file or system definition file, add an element to specify a value for the variable. The attribute must specify the type of the value, the name of the variable, and the value for the variable, for example.
<simObject objectType="1:1:1:225:1:1:3:0" platform="platforms\Ground_Vehicle.ope">
<bool paramName=”entity-is-organized”>True</bool>
...
</simObject>
Although you can add these entries by hand, it is highly recommended that you do so in the Simulation Object Editor by applying platform updates. When you apply platform updates, all changes to platform and system definition files get applied to all simulation objects that use them. For details, please see “Applying Platform Updates,” on page 64-19.
!
!
If you do not add an attribute to an .entity file that references the modified platform or system definition file, a default value will be used, which may result in unexpected behavior.
When you add new variable bindings, you can make them editable in the Simulation Object Editor. Variables in platform files are edited in the Attributes panel (the right- most panel) of the Simulation Object Editor. They include variables such as speed, mass, and bounding volume. Variables in system definition files are edited in the Prop- erties dialog boxes for the individual systems. The procedures for adding these two types of variables to the Simulation Object Editor are different.
Variable bindings for platform files are edited in the Attributes Panel. The layout of this panel is controlled by .ui files. The Simulation Object Editor has a .ui file for each plat- form. The files are in ./data/simulationModelSets/<model_set>/gui/ui. You can edit .ui files in a text editor or in Qt Designer.
You do not need a developers license to use Qt Designer. You will need to download the version of Qt used by your version of VR-Forces. Please see VR-Forces 4.5 Release Notes for details.
In “Adding Variable Bindings to Platform and System Files,” on page 69-21, we added a new variable binding to the Ground_Platform.ope file. The corresponding entry in ground-vehicle-param.ui file would be:
<item>
<widget class="QCheckBox" name="entity_is_organized">
<property name="text">
<string>Is Organized</string>
</property>
</widget>
</item>
Notice that the variable name entity-is-organized in the OPE file is expressed as enti- ty_is_organized in the .ui file. You must use underscores in the .ui file for the variable name.
Whether you edit a .ui file by hand or using Qt Designer, you need to understand how data entry elements are defined. This varies depending on the type of widget used, such as text box, check box, option button, or list.
It is beyond the scope of this manual to explain Qt Designer and GUI layout. However, at the most basic level, the controls in the GUI are specified in item elements. Each item has a widget that has a class and an objectName. (The XML attribute is name. In Qt Designer it is objectName.)
The objectName for an item is the platform variable name with dashes changed to underscores. For example the objectName for the short-name variable is short_name.
If an item has a label, the objectName must be <variable_name>_label. For example, the objectName for the Short Name label is short_name_label.
Each data entry widget creates a data entry field that is appropriate for the variable type (integer, real, string). Other elements (systems, vector entry) create more complex controls.
element_type. String property that can be assigned a particular reader/writer (vari- able) type (for example, DtRwReal) or any other internal type that has been regis- tered for element creations. These types are:
single_system_selector
multi_system_selector
sensor_signatures
aggregate_composition
aggregate_formation_editor
push_button
scripted-movement-system-selector.
enable_if_checked. String property that defines a check box element. If the check box is selected, the variable is enabled. If clear, it is disabled.
signal_slot. String element. If defined for a push button, a particular slot is called when that signal is sent. The format is:
The Object Parameter Database — Configuring Units
<signal>;<referencedControl>;<slot>released();bounding_volume; onCalculateSupportPointsChanged()
The referenced control is the name of an existing control in the .ui file.
When you add a system to a simulation object in the Simulation Object Editor, you can edit its properties. The Properties dialog box is not configured in a .ui file. It is gener- ated based on the metadata section of the system definition file. Suppose that you want to change the rounds per minute parameter in 120mm-gun.sysdef to a variable binding. You would create the variable binding as described in “Adding Variable Bindings to Platform and System Files,” on page 69-21 and you would add details to the metadata as shown in the following example:
(weapon-120mm-gun
...
(rounds-per-minute $rounds-fired-per-minute)
...
(meta-data
(parameter-data-list (bool-parameter-data
(parameter-name "rounds-fired-per-minute") (variable-type "DtRwInt")
(display-label "Rounds Fired Per Minute") (display-units "")
(source-units "") (default-value True)
)
...
All units have the parameter-type aggregate-object-param.
In entity-level scenarios, most functionality resides in entities and units have relatively few individual parameters. The principle function of the various elements is to specify controllers and formations, and to specify the echelon-level for the different levels of units.
In aggregate-level scenarios, aggregated units can have many systems and parameters. Disaggregated units, like their entity-level counterparts, have limited capabilities. Both types of unit have the parameter-type aggregate-object-param.
The Object Parameter Database — Configuring Tactical Graphics
The object parameter database includes parameters for tactical graphics. Tactical graphics provided with VR-Forces have the parameter-type vrf-base-object-param. You should not change the parameters for the objects provided with VR-Forces. However, if you are using the VR-Forces toolkit, you could create other types of tactical graphics. You would have to include parameters for them in the object parameter database.
The files that make up a simulation model set, such as .entity files and system definition files, usually contain references to other files in the SMS. These supporting files may also have references to other configuration files. VR-Forces supports the file relation- ships by specifying files using relative paths and by defining directory variables. This allows you to maintain custom simulation model sets outside of the VR-Forces file hier- archy and not have to move them every time you install a new version of VR-Forces.
Examples of directory variables are in the SMS file and OPD file. The following lines from the EntityLevel.sms file show a binding (model-set-directory) and its use:
(simulation-model-set (variable-bindings
(DtRwString
(model-set-directory "EntityLevel")
)
(DtRwString
(opd-dir "$(model-set-directory)")
)
...
)
(opd-file "$(model-set-directory)\vrfSim.opd")
(physical-world "$(model-set-directory)\physicalWorldParams.mtl")
...
)
Similarly, the vrfSim.opd file has bindings, which are then used in .entity files, as shown. From vrfSim.opd:
(variable-bindings (DtRwString
...
(system-dir "$(opd-dir)/vrfSim/systems"
)
(DtRwString
(ammoselect-dir "$(opd-dir)/vrfSim/ammoselect"
)
...
)
From M1A2_Tank.entity (system-dir variable):
<componentSystem systemName="damage"
platform="@(system-dir)/damage/ground-heavy-armor.sysdef"/>
The Object Parameter Database — Updating Object Parameter Database Files for New Releases
New releases of VR-Forces frequently include new components and new parameters for existing components. If you are using a customized SMS you will probably want to update it to take advantage of the new components and parameters. Unfortunately, there is no automatic way to migrate an object parameter database. Here are some guidelines and options for migrating your SMS:
If you have created new simulation objects using the VR-Forces-installed system definition files, copy their .entity files into the ./data/simulationModel- Sets/<model_set>/vrfSim directory. They will pick up all changes to systems, plat- forms, and other configuration files.
Copying .entity files does not copy changes made to element definitions and entity type mappings. You will have to update element definitions and entity type mappings using the Simulation Object Editor or the Visual Models Editor and Entity Type Mappings dialog box.
If you have added new systems using the VR-Forces-installed components, copy the system definition files and any other configuration files, such as damage files or detection files, to the appropriate directories in the simulation model set.
If you have added new simulation objects or systems that rely on new components created with the VR-Forces API, you will have to rebuild the components using the new version of VR-Forces and copy all required files as described in the previous paragraphs.
Use multiple simulation model sets. VR-Forces can load multiple simulation model sets (for details, please see “Specifying Multiple Simulation Model Sets,” on
page 7-8). If your customizations do not overlap the default SMS or are relatively easy to separate from the default SMS, you can create a separate SMS and load it along with the SMS supplied with VR-Forces.
Include the VR-Forces-supplied SMSs in your customized SMS. For information about including SMSs in other SMSs, please see “Including Simulation Model Sets in other Simulation Model Sets,” on page 64-6.
The Object Parameter Database — Updating Object Parameter Database Files for New Releases
This chapter describes how to use the OPD Editor to edit simulation model sets (SMS).
The Object Parameter Database Editor 70-2
Loading a Simulation Model Set 70-3
Editing Platforms and Systems 70-4
Creating a New Platform or System from an Existing One 70-4
Editing Individual Parameters 70-6
Deleting Parameters and Components 70-7
Adding New Components and Parameters 70-8
Changing A Component’s Priority 70-9
Adding New Resource Parameters 70-11
Regenerating Platform Files 70-12
Saving Changes to the Object Parameter Database 70-12
Using the OPD Editor — The Object Parameter Database Editor
The Object Parameter Database Editor (OPD Editor) is a graphical user interface for editing platforms and systems. When you use the OPD Editor instead of a text editor, you do not have to worry about getting MTL or XML syntax correct in your files. It also quickly gives you access to all the platforms and systems without needing to know which particular files they use.
If you want to edit or add simulation objects, use the Simulation Object Editor.
To start the OPD Editor, on the Start menu, choose MÄK Technologies VR- Forces 4.5 Tools OPD Editor. The OPD Editor opens (Figure 70-1).
To start the OPD Editor from the Windows or Linux command line:
Change directory to ./bin64.
Run vrfOpdEditor.
Using the OPD Editor — Loading a Simulation Model Set
To edit a simulation model set, you must load it into the editor.
To load a simulation model set:
Choose File Open Simulation Model Set. An Open dialog box opens. By default it opens to ./data/simulationModelSets.
Select the SMS you want to load, for example, EntityLevel.sms.
Click Open. The SMS is loaded. Platforms are listed on the Platforms tab, systems on the Systems tab.
Figure 70-2. OPD Editor with SMS file loaded
Platforms and systems are similar in organization and construction. They simply configure objects at different levels. They have a set of general parameters, components, and possibly resources, signatures, subordinate objects, and a soil list. These parameters are organized into tabs. Within each tab, the parameters and their values are listed.
This section explains how to edit an object’s parameters, how to delete parameters, and how to restore parameters that you have changed or deleted.
Parameter definitions are documented by component in the online help for the OPD Editor in the Object Parameter Descriptions folder. Individual parameter definitions are displayed in the Parameter Reference panel of the OPD Editor. The definitions are also in the header files and class documentation.
You can add new platforms and systems to the object parameter database using an existing one as a template.
To add a new platform based on an existing platform:
Select the platform on which you want to base the new one.
Choose Platforms Create Platform From Existing. The Create New Platform dialog box opens.
Type a name for the new platform.
Click OK.
Edit the parameters.
Save the object parameter database.
To add a new system based on an existing system:
Select the system on which you want to base the new one.
Choose Systems Create System From Existing. The Create New System dialog box opens.
Type a new name for the system definition file or click Browse and select an existing file name.
Type a name for the new system.
Optionally, specify configuration files to copy:
Click the >>> button. The dialog box expands to display the Copy Files group box.
Select the file types that you want to copy.
Click OK.
Edit the parameters.
Save the object parameter database.
Figure 70-3. Parameter hierarchy after edits
To edit a parameter:
Select the parameter by clicking in the Name or Value column. The Value field becomes editable.
Enter the new value. In most cases you enter a new value by typing it. If a param- eter value has a File Chooser button (Figure 70-4), click the button to open a File Chooser dialog box. If the value has an Edit button, click the button to open a window that allows you to edit the file.
File Chooser Edit
Variable State Restore
Figure 70-4. Parameter value buttons
The parameters on the General tab cannot be deleted. Parameters on the other tabs can be deleted.
To delete a parameter or component:
Select the parameter or component in the Value list.
Click the Delete button at the right end of the parameter entry (Figure 70-5).
Delete
If you change a value or delete a parameter or component, you can restore the original value. You can restore at the individual parameter level and at any level in a given hier- archy of entries (Figure 70-3). For example, you can restore a change to the at-distance parameter for the move-to controller, all edits made to the move-to controller, or all edits made to all Controllers. However, since Actuators are not part of the Controllers hier- archy, restoring a change at the Actuators level would not affect changes to Controllers.
To restore a parameter or component:
Select the parameter to restore. If you are restoring a deleted parameter or compo- nent, select the parent component.
To undo all changes to a platform or system, choose Platforms Restore Platform
or Systems Restore System.
You cannot add new parameters to the General tab. You can add new components, resources, subordinates, and signatures if an object supports them.
For most platforms, the Components tab does not list all of the components that apply to the entity. This is because many components are referenced through the systems that are attached to an instance of a platform. If you do not see a component that you are looking for in a platform’s component list, look at the component list for the relevant system in the Systems list.
Before you add a component to a platform, consider whether or not the component should be added as part of a new or existing system, rather than being added directly to the platform.
To add a component to a platform:
Select the Components tab.
Select the component type (Actuator, Controller, Sensor) you want to add.
Click the Add button (Figure 70-6). The Create New Component dialog box opens. The Component list lists all components that are available for this object.
From the Component list, select the component you want to add.
Click OK. The component is added to the object.
Using the OPD Editor — Adding New Components and Parameters
When you change a component’s priority, the other components are reprioritized as needed. All affected components are listed in bold.
To change a component’s priority:
Select the component you want to edit.
Click the up or down arrow on the value line (Figure 70-7).
Change Priority Figure 70-7. Change Priority buttons
When you add a component, you must also add connections between the component and other components it interacts with.
To add a connection:
Click the Add button (Figure 70-6). The Create Connection dialog box opens (Figure 70-8).
Choose a source component from the Source list.
Enter the port group for the source component. You must know the name of the port group you need to use. For a list of components and port groups, see the online help.
Choose the destination component from the Destination list.
Enter the port group for the destination component. You must know the name of the port group you need to use.
Click OK. The connection is added to the Connections list.
Using the OPD Editor — Editing Variables
To add a resource parameter to an object:
Select the Resources tab.
Select Resources.
Click the Add button (Figure 70-6). The Create Resource dialog box opens.
Figure 70-9. Create Resource dialog box
In the Resource Name box, enter the name of the resource you want to add. Resource names must start with a letter, not a number. You are responsible for knowing that this is a valid resource supported by your implementation of VR- Forces.
In the Full Amount box, enter the amount of the resource to assign to this object.
Select a resource type from the Resource Type list.
Click OK. The resource is added to the object.
The object parameter database uses variables to specify the location of supporting files, such as ammo selection files, system definition files, and formation files. You can edit these variables. (For information about variables, please see “Adding Variable Bindings to Platform and System Files,” on page 69-21.)
To edit variables:
Select the platform whose variables you want to edit.
Choose Platforms Edit Variables. The Edit Variables dialog box opens.
Change the variable values as desired.
Click OK.
Using the OPD Editor — Regenerating Platform Files
To regenerate platform files, choose Platforms Regenerate Platform Files.
To save an edited object parameter database, choose File Save.
This chapter explains how to configure sensors and sensor signatures.
Adding a New Sensor to a Simulation Object 71-2
Editing a Sensor System Definition File 71-4
Specifying a Sensor Signature 71-5
Adding Detection Types or Why Doesn’t My Sensor Detect Anything? 71-9 Adding a New Sensor Type 71-9
Illumination and Time of Day 71-12
VR-Forces includes several sensor systems and you can add them to simulation objects using the Simulation Object Editor. This section provides additional details about how sensors are configured. A complete sensor configuration requires the following:
One or more componentSystem elements in the .entity file for sensor systems.
A list of sensor signature values in the .entity file for the sensor types that can detect the entity type.
A signature propagator entry in the ./data/simulationModelSets/<model_set>/physi- calWorldParam.mtl file (one per sensor type).
VR-Forces includes sensors such as radar, infrared, visual, magnetic anomaly detector (MAD), and sonar. The simulation objects configured in the object parameter database are configured with appropriate sensors and sensor signatures. For details about sensor components and how they work, please see API documentation.
All sensors provided with VR-Forces are signature-object-sensors. They are distin- guished by the domain in which they operate (for example, visual, radar, infrared, MAD, or sonar).
To add a sensor to a simulation object by editing its .entity file:
Copy an existing componentSystem element in the .entity file and paste it into the file.
Change the systemName to be unique, for example, sensor-2.
Change the name of the system definition file to point to the sensor you want to add.
Change the values for the variables that must be specified for the sensor.
If you add a sensor that has been configured to use the auto-connection feature (all sensors provided by MAK support auto-connections), its connections are handled auto- matically. (For details, please see “Configuring System Connections,” on page 69-18.)
If you add a new type of sensor, you must connect it to input through its input port and then send the data to its output port for the appropriate controller. The sensor gets input through its object-types-to-detect input port. It sends that data out through its detected-objects output port. The connections for the visual sensor, in visual- sensor.sysdef are:
(connect system:object-types-to-detect visual-sensor:object-types-to- detect)
(connect visual-sensor:detected-objects system:detected-objects) (connect system:sensor-offset visual-sensor:sensor-offset)
If you were to create an acoustic sensor, its connections would look like this:
(connect system:object-types-to-detect acoustic-sensor:object-types-to- detect)
(connect acoustic-sensor:detected-objects system:detected-objects) (connect system:sensor-offset acoustic-sensor:sensor-offset)
The preferred method for editing a sensor system definition file, as with all system defi- nition files, is to edit it in the OPD Editor. You can also edit the file by hand. The following example is from the visual sensor system definition file:
(visual-sensor
(component-descriptor-type "signature-sensor-descriptor") (component-type "signature-sensor")
(min-tick-period 2.000000)
(min-tick-period-variance 0.100000) (tick-period-uses-real-time False) (process-state-repository-name "") (process-state-repository-type "") (is-enabled True)
(detect-only-hostile-forces False) (detection-types )
(detect-destroyed-objects False) (sensor-geometry
(in-range
(range $max-range)
)
)
(sensor-domain "visual")
(sensor-offset $sensor-position) (sensor-positional-error 0.000000) (detection-level-determinator
(determinator-type "signature-detection-level-determinator") (detection-level-to-set-hostility 3)
(combat-identification-level-table-file
"$(detection-dir)\std-visual-detection-table.csv")
)
)
)
(controllers
)
(actuators
)
(connections
(connect system:object-types-to-detect visual-sensor:object-types-to-detect)
(connect visual-sensor:detected-objects system:detected-objects) (connect system:sensor-offset visual-sensor:sensor-offset)
)
As you can see from viewing the file, most of the parameters that you would want to vary from entity to entity are variables whose values are set in the .entity file.
The modifiers specify multipliers for the base value, based on the current state of the object. For example, a simulation object might have a base value of 5.0 for its visual signature, and a modifier of 1.5 when moving. This means the signature of the entity is
7.5 when moving and 5.0 when not moving.
The following is the sensor signature block from a DI with M4:
(sensor-signatures (visual
(base-signature $visual-signature) (modifiers
(file
(external-file
(filename "signatureRules/lifeform-visual-rules.mtl")
)
)
(file
(external-file
(filename "signatureRules/visual-illumination-rules.mtl")
)
)
)
)
(infrared
(base-signature $infrared-signature) (modifiers )
)
(radar
(base-signature $radar-signature) (modifiers )
)
)
This sensor-signature block shows that a DI M4 can be detected by visual, infrared, and radar sensors. The base-signature values are variables. Their values come from the .entity file.
<sensorSignatures>
<real paramName="visual-signature">1.2</real>
<real paramName="infrared-signature">1.2</real>
<real paramName="radar-signature">0.25</real>
</sensorSignatures>
The visual sensor has two modifiers. The file lifeform-visual-rules.mtl is as follows:
(signature-modifiers (speed-less-than (speed 1.0)
(multiplier 0.5)
)
)
This indicates that if the entity’s speed is less than 1 KMH, multiply the base signature by 0.5. A slowly moving entity is less likely to be seen.
For details about the visual illumination rules modifier, please see “Illumination and Time of Day,” on page 71-12.
If you do not want a simulation object to be detectable by a particular type of sensor, remove the sensor signature from the .entity file. If you want it to be detectable by an additional sensor type, add its sensor signature to the .entity file. You can edit the values of sensor signatures in the Simulation Object Editor. You cannot add sensor signatures in the Simulation Object Editor. You can edit the values of sensor-signatures and add new sensor signatures in the OPD Editor.
Table 71-1 lists the sensor signatures that VR-Forces uses for general categories of simu- lation objects in EntityLevel.sms. (These categories do not match the categories list in the Simulation Object Editor. They represent a more granular approach to categorizing simulation objects for the purpose of applying a consistent set of sensor signatures.)
Table 71-1: Entity-level sensor signatures (Sheet 1 of 3)
Entity Category (with example) | Visual | Radar | Infrared | Sonar Active | Sonar Passive | MAD |
Military Fixed Wing - stealth technology | 2.5 | 4 | 6 | N/A | N/A | N/A |
Military Fixed Wing - Large Jet (Cargo) | 7 | 30 | 30 | N/A | N/A | N/A |
Military Fixed Wing - Small Jet (Fighter) | 4 | 6 | 20 | N/A | N/A | N/A |
Military Fixed Wing - Large Prop | 5 | 25 | 15 | N/A | N/A | N/A |
Military Fixed Wing - Small Prop | 4 | 20 | 15 | N/A | N/A | N/A |
Military Fixed Wing - Large UAV (Pred- ator) | 5 | 20 | 16 | N/A | N/A | N/A |
Military Fixed Wing - Small UAV | 2 | 2 | 1.5 | N/A | N/A | N/A |
Military Fixed Wing - Micro UAV (Hand Launch) | 1 | 0.5 | 0.5 | N/A | N/A | N/A |
Table 71-1: Entity-level sensor signatures (Sheet 2 of 3)
Entity Category (with example) | Visual | Radar | Infrared | Sonar Active | Sonar Passive | MAD |
Civilian Fixed Wing - Large (Passenger) | 10 | 40 | 35 | N/A | N/A | N/A |
Civilian Fixed Wing - Medium (regional) | 7 | 30 | 30 | N/A | N/A | N/A |
Civilian Fixed Wing - Small (Cesna) | 5 | 20 | 12 | N/A | N/A | N/A |
Small Rotary Wing | 4 | 20 | 20 | N/A | N/A | 0.3 |
Medium Rotary Wing | 5 | 25 | 25 | N/A | N/A | 0.3 |
Large Rotary Wing | 7 | 30 | 30 | N/A | N/A | 0.3 |
Military/Civilian Large Cargo Ship (tanker/cargo) | 35 | 40 | 30 | 10 | 8 | N/A |
Military Aircraft Carrier | 35 | 40 | 30 | 10 | 8 | N/A |
Military Cruiser | 25 | 30 | 25 | 8 | 6 | N/A |
Military Destroyer | 20 | 28 | 25 | 8 | 6 | N/A |
Military Frigate | 18 | 25 | 25 | 8 | 6 | N/A |
Military Large Patrol (Corvette) | 18 | 25 | 25 | 6 | 4 | N/A |
Military Small Patrol (covered) | 10 | 25 | 25 | 3 | 2 | N/A |
Military Small (zodiac) | 4 | 6 | 8 | 2 | 1.5 | N/A |
Civilian Large Commercial Passenger (Cruise) | 45 | 50 | 50 | 10 | 8 | N/A |
Civilian Medium Commercial | 25 | 40 | 35 | 8 | 5 | N/A |
Civilian Small Commercial (tug) | 15 | 30 | 35 | 4 | 3 | N/A |
Civilian Private Medium | 15 | 25 | 25 | 4 | 3 | N/A |
Civilian Private Small (24->30ft day cruiser) | 10 | 25 | 25 | 3 | 2 | N/A |
Civilian Private Micro (jet ski) | 5 | 9 | 10 | 1 | 2 | N/A |
Table 71-1: Entity-level sensor signatures (Sheet 3 of 3)
Entity Category (with example) | Visual | Radar | Infrared | Sonar Active | Sonar Passive | MAD |
Civilian Sailboat (J-24) | 15 | 20 | 10 | 2 | 0.5 | N/A |
Small Lifeboat (bright colors) | 7 | 12 | 15 | 1 | 1 | N/A |
Large Lifeboat (bright colors) | 10 | 15 | 15 | 1 | 1 | N/A |
Military Submarine - Large (Ohio) | 2 | 3 | 2 | 1 | 0.01 | N/A |
Military Submarine - Medium (LA) | 1.5 | 3 | 2 | 0.75 | 0.01 | N/A |
Military Submarine - Small | 1.5 | 3 | 2 | 0.5 | 0.25 | N/A |
Military Submarine - Torpedo (non decoy) | 0 | 0 | 0 | 1 | 2 | N/A |
Human (no camou- flage) | 1.2 | 0.25 | 1.2 | N/A | N/A | N/A |
Human (with camouflage) | 0.5 | 0.25 | 0.75 | N/A | N/A | N/A |
Human in Water (with bright vest) | 2 | 2 | 1.5 | N/A | N/A | N/A |
Human in Water (no vest) | 0.75 | 2 | 1.5 | N/A | N/A | N/A |
Civilian Passenger Car | 4 | 0.5 | 4 | N/A | N/A | N/A |
Civilian Truck/Bus | 6 | 1 | 6 | N/A | N/A | N/A |
Military Artillery - large | 3 | 0.75 | 4 | N/A | N/A | N/A |
Military Artillery - small | 1 | 0.5 | 2 | N/A | N/A | N/A |
Military Large vehicle (Logistics) | 5 | 1 | 5 | N/A | N/A | N/A |
Military Medium vehicle (Tank) | 3 | 0.5 | 4 | N/A | N/A | N/A |
Military Small vehicle (Jeep/Tech- nical) | 1 | 1 | 2 | N/A | N/A | N/A |
Military Micro vehicle (human sized or smaller) | 0.5 | 0.25 | 1 | N/A | N/A | N/A |
Sometimes VR-Forces users add a sensor to a simulation object and then wonder why it doesn’t detect anything. This problem occurs when a simulation object does not have a weapon. In this case, the sensor’s types-to-detect parameter is empty. To have a simulation object that does not have a weapon detect other simulation objects, specify object types to detect in the detection-types parameter in the sensor’s system defi- nition file, for example:
(detection-types
(entity-type 1 (1 3 -1 -1 -1 -1 -1))
(entity-type 1 (1 4 -1 -1 -1 -1 -1))
)
You can easily add new sensor types to your simulation objects. Suppose that you want to add an acoustic sensor. You would do the following:
Add a block to the signature-propagator-params block in physicalWorldParams.mtl.
Add a sensor componentSystem element to each entity that can detect targets acoustically.
Add a sensor signature to each simulation object that can be detected acoustically.
The physicalWorldParams.mtl file specifies the list of sensors available and the propa- gator to use for each. The following is a portion of this file:
(physical-world-params (signature-propagator-params
(radar
(propagator-descriptor-type "standard-propagator-descriptor") (propagator-type "standard-propagator")
(check-line-of-sight True)
)
(visual
(propagator-descriptor-type "standard-propagator-descriptor") (propagator-type "visual-propagator")
(check-line-of-sight True)
...
)
)
)
If you edit the file to add an acoustic sensor, it might look like the following:
(physical-world-params (signature-propagator-params
(visual
(propagator-descriptor-type "standard-propagator-descriptor") (propagator-type "visual-propagator")
(check-line-of-sight True)
)
(acoustic
(propagator-descriptor-type "standard-propagator-descriptor") (propagator-type "standard-propagator")
(check-line-of-sight False)
)
...
)
)
You do not have to be able to see a simulation object to hear it, so you do not need to check line of sight.
To add a new sensor component, follow the procedure in “Adding a New Sensor to a Simulation Object,” on page 71-2. A new acoustic sensor might look like the following:
(acoustic-sensor
(component-descriptor-type "signature-sensor-descriptor") (component-type "signature-sensor")
(min-tick-period 2.000000)
(min-tick-period-variance 0.100000) (tick-period-uses-real-time False) (process-state-repository-name "") (process-state-repository-type "") (detect-only-hostile-forces False) (detection-types )
(detect-destroyed-objects False) (sensor-geometry
(in-range
(range $max-range)
)
)
(sensor-domain "acoustic") (sensor-offset $sensor-position)
(sensor-positional-error 0.000000) (detection-level-determinator
(determinator-type "signature-detection-level-determinator") (detection-level-to-set-hostility 3)
(combat-identification-level-table-file
"$(detection-dir)\std-acoustic-detection-table.csv")
)
)
)
(controllers
)
(actuators
)
(connections
(connect system:object-types-to-detect acoustic-sensor:object-types-to-detect)
(connect acoustic-sensor:detected-objects system:detected-objects)
)
!
!
You can call the sensor whatever you want, but the name must not start with a number.
(sensor-signatures (visual
(base-signature 4.000000) (modifiers )
)
(acoustic
(base-signature 2.000000) (modifiers )
)
...
)
You can probably see simulation objects at a greater distance than you can hear them, so the acoustic sensor has a lower base-signature value than the visual sensor.
./data/simulationModelSets/<model_set>/vrfSim/signatureRules/visual-illumination-
rules.mtl:
(signature-modifiers (environmental
(modifier-coefficients 1.0 0.1)
)
)
“Specifying a Sensor Signature,” on page 71-5 shows how this file can be referenced in a sensor signature. Given this file, the modifier coefficients are applied to the illumina- tion value, as follows:
Multiplier = 1.0 * illumination + 0.1
The illumination value is derived from the time of day based on parameters in Global- Environment.ope:
...
(actuators
(global-environment-actuator
...
(sunrise-time 21600.000000)
(sunset-time 64800.000000)
(daylight-illumination 1.000000)
(night-illumination 0.100000)
(day-night-transition-time 7200.000000)
)
)
where:
sunrise-time is the time at which the daylight model changes from night to day, in seconds past midnight.
sunset-time is the time at which the daylight model changes from day to night, in seconds past midnight.
daylight-illumination is the percent illumination during the full daylight hours.
night-illumination is the percent illumination during the full night hours.
day-night-transition-time is the period of time, centered on sunrise and sunset times, where the illumination value transitions from daylight to night, or night to daylight. During this time period, the illumination level is a linear progression between the night and daylight illumination levels.
Configuring Sensors — Detection Tables
The detection tables determine the level of knowledge that a simulation object has of detected simulation objects. The detection level is used in the Detect Entity condition in plans.
Detection tables are comma-delimited files that are most easily read in a spreadsheet. As illustrated in Figure 71-1, each column represents a detection interval, in seconds, from 0 through 160. Each row represents an apparent signature from one through 4. (An apparent signature is a simulation object’s absolute signature after being modified by factors such as terrain and distance. For details, please see API documentation.)
Figure 71-1. Detection table displayed in a spreadsheet
The detection level is determined by finding the intersection of the apparent signature and the detection interval. For example, if a simulation object with an apparent signa- ture of 3 has been detected for 40 seconds, its detection certainty level is 4 (full knowl- edge).
The apparent signature is the ratio of the sensor signature given for the simulation object (in kilometers) to the actual range. So if the apparent signature = 1, the detection interval shows the increase in combat ID level over time when the target is at the range given by the sensor signature. If the apparent signature is 2, the detection interval shows the detection progression at 1/2 that range, and so on.
The numbers in the table represent the certainty levels as follows:
1 – Detected.
2 – Classified.
3 – Identified.
4 – Full Knowledge.
For details about CID detection levels, please see “Detecting Targets,” on page 9-13.
This chapter describes configuration files for weapon systems in EntityLevel scenarios. Introduction to Entity-Level Weapon Systems 72-3
Configuring Direct Fire Ballistic Weapons 72-4
Damage Probability Tables 72-10
Configuring Missile Systems 72-11
Laser Guided Missile Launcher 72-13
Laser Guided Missile Projectile 72-13
Configuring Indirect Fire Weapons 72-14
Configuring Fixed Weapons 72-16
Configuring Bomb Bay Weapon Systems 72-17
Calculating Damage from Munitions 72-17
Configuring Damage-by-Power 72-18
Configuring the Power of a Detonation 72-19
The Damage File for Damage-By-Power 72-21
Configuring Damage-by-Ammo-Type 72-25
Configuring Damage for Damage-by-Ammo-Type 72-26
Configuring Damage for Dynamic Terrain 72-28
Configuring Weapon Systems and Munition Damage
High Fidelity Terrain Damage 72-29
Direct Fire Configuration Examples 72-30
Direct Fire Weapon Damage-By-Power Example 72-31
Direct Fire Weapon Damage-by-Ammo-Type Example 72-36
Configuring Weapon Systems and Munition Damage — Introduction to Entity-Level Weapon
Systems
Simulation objects in entity-level scenarios have many weapon systems. They all fall into one of the following types:
Ballistic direct fire, such as rifles and the main gun on a tank.
Self-propelled or guided munitions, such as missiles and rockets.
Indirect fire, such as artillery, naval guns, mortars, and hand grenades.
Fixed munition, such as mines and IEDs.
Bomb bay. A weapon system for dropping bombs.
Weapon systems are defined by a system definition (.sysdef) file that includes multiple component definitions. Typically a weapon system includes at least one controller that controls aiming and firing and an actuator that models the physical characteristics of the weapon. Some weapons create munitions when they fire, so the engagement process involves an additional simulation object with its own movement system, weapon (warhead) system, or both.
All objects with weapon systems can engage using a task such as Fire At Target, Fire For Effect, Throw Grenade, and so on.
Simulation objects often engage targets autonomously. Objects that engage autono- mously require a sensor to detect targets. Weapon systems are configured to engage certain target types, and this information is passed to the sensor so that the appropriate enemy objects can be detected.
Automatic engagements are controlled by a target selection controller, which is a component separate from any one weapon system. This controller is specified in the platform (.ope) file. Weapons pass information to and from the target selection controller through a weapon interface. This is a process state repository used to keep track of targets for the weapon and the number of rounds to fire at that target. No port is used, no connections are necessary; it is created for you. The target selection controller keeps a list of all weapon systems’ weapon-interfaces, one for each system.
Weapon systems generate the fire interactions that are published on the network for an engagement. Detonation actions may be generated by the weapon or by the munition it launches.
Once there is a detonation, damage is determined by the target. Damage may be configured in one of two ways: by specifying the power of the munition and the damage caused to a target by a detonation of a given power, or by specifying damage probabilities for each munition type against each target type. For more information, please see “Calculating Damage from Munitions,” on page 72-17.
Throughout this chapter, we include snippets from system definition files and other configuration files, but usually without explaining what the various parameters mean. If you want to know more about the parameters, open the referenced system files in the OPD Editor. It has context-sensitive help for most parameters. The online help for the OPD Editor also describes many of the parameters for the various systems.
If you want general descriptions of what the various systems do and which simulation objects use them, please see the tables in Appendix D, Systems and System Usage.
Entities that have direct fire weapons can fire in response to a fire target task and they can detect targets through their sensors and automatically fire at the targets. Entities have to be able to:
Know what targets they can fire at.
Detect the targets.
Determine the ammunition to use.
Acquire the target and fire at it.
If you want to create a completely new type of weapon system, you must write code for the sensors, controllers, and actuators that it requires. However, if you need a system that is similar to an existing system, you can often create the new system by copying and modifying the configuration files of the existing system. To do so, you must under- stand the relationships between the different configuration files to allow you to:
Configure a weapon system.
Specify the simulation object types that can use the system.
Specify the simulation object types that can be damaged by the system.
Specify the amount of damage a simulation object receives from a munition. The files that manage these relationships are:
The ammo select file. Specifies the type of munition to use for each type of simula- tion object that a weapon can fire at.
The damage system. Specifies the types of munitions that a simulation object is vulnerable to and the damage file to use to determine the probability of damage.
The damage file. Specifies the probability that a simulation object will sustain damage and the type of damage it will sustain when hit by a particular munition in a particular location.
The hit file. Specifies the probability that a ballistic gun will hit a target at different distances. The hit file is not used for projectile weapons and indirect fire.
For detailed examples of how to configure a direct fire weapon, please see “Direct Fire Weapon Damage-By-Power Example,” on page 72-31 and “Direct Fire Weapon Damage-by-Ammo-Type Example,” on page 72-36.
The weapon does the following:
Acquires the target.
Selects the ammunition for the target using the ammo select file.
Checks that it has that resource.
Determines if it hits target.
Sends a fire interaction.
After a delay based on distance and muzzle speed, it sends a detonation interaction.
Simulation objects that have direct fire weapons detect targets through their sensors and automatically fire at the targets. Sensor systems can specify what types of targets to detect (using the detection-types parameter). The weapon systems can also tell the sensors what they want to target.
Each weapon system has an associated weapon interface. The targeting-control parameter takes a list of desired target types and creates a target selection criteria object, which is then set in the weapon interface. The following code shows the targeting control for handheld-AK47.sysdef file. It also shows the ammo select file.
(main-gun-control
(component-descriptor-type "ballistic-gun-ctlr-descriptor") (component-type "ballistic-gun-controller")
...
(ammo-select-table-file
(filename "$(ammoselect-dir)\AKA762.asl")
)
(rounds-per-trigger-pull 5) (targeting-control
(target-priorities (entity-priority
(entity-type 3 1 -1 1 -1 -1 -1)
(priority 1)
)
(entity-priority
(entity-type 3 -1 -1 -1 -1 -1 -1)
(priority 2)
)
)
...
)
The platform file for the entity uses its target selection controller to iterate through each weapon interface to create a list of object types to detect, which it outputs on its object- types-to-detect port.
Each sensor on the entity connects to this port to know what types of objects to detect (Figure 72-1).
Weapon system
ballistic-gun-controller
targeting-control
ballistic-gun-controller
targeting-control
Simulation Object
target-selection-controller (from OPE file)
object-types-to-detect
Sensor System
Sensor System
Sensor System
Sensor System
Figure 72-1. Direct fire sensor input
The ballistic gun controller descriptor refers to an ammo select table file, which contains the ammo select table for that controller. Each entry in this file specifies a target type (using the best match method) and a prioritized list of ammunition that should be used for that type of target (highest priority listed first). (The best match method is described in “The Best Match Method,” on page 69-7.) The name of the entry is not used, and so may be something descriptive for readability. Each entry has the following fields:
target-type – a 7-digit entity type enumeration, which can use -1s to denote wild- cards.
ammo – list of ammunition entries. The names of the ammunition entries are assumed to be the resource names. If the resource name is found in the Object Resource Manager, the amount of the ammunition is decremented appropriately, and is not used if the resource amount is 0. In this case, the next ammunition entry (if any) in the ammunition list is used. Each ammunition entry has the following fields:
munition-type – 7 digit object type enumeration. This is the object type that is used in the fire and detonation interactions created, and should NOT contain
-1s.
tracer-type – 7 digit object type enumeration. This parameter is optional. Use it if you want a weapon to support tracer rounds.
warhead – VR-Link warhead enumeration value to use in fire and detonation interactions for this munition.
The following is an example of an Ammo Select Table (M16.asl):
(ammo-select-table
(lifeform ;; matches any lifeform (target-type 3 -1 -1 -1 -1 -1 -1) (ammo
(M16A2-556mm ;; these names need to match resource names (munition-type 2 8 225 2 1 1 0)
(tracer-type 2 8 225 2 1 2 0)
(warhead 0)
)
)
)
(civilian-vehicle ; "technical" (target-type 1 1 -1 27 -1 -1 -1) (ammo
(M16A2-556mm ;; these names need to match resource names (munition-type 2 8 225 2 1 1 0)
(tracer-type 2 8 225 2 1 2 0)
(warhead 0)
)
)
)
)
A weapon system definition file specifies a hit probability file. This file contains a hit probability table that is used by the system’s actuator to determine whether or not it hits a target that it fires upon. A hit probability table has one or more entity-range entries. The name of the entity-range entry is not used, and can be something descriptive. An entity-range entry has the form:
entity-type – 7 digit entity type enumeration, which may use -1s as wildcards.
range-determinant – a range determinant can be either a list of probability-range entries with the name “range-list”, or a probability-coefficient list with the name “coefficients”.
range-list – a list of probability-range entries. A probability-range entry has a name, “range”, a range value (in meters) and a list of probability entries. The entry applies to targets in the range from the last entry to the current one (or from 0.0 in the case of the first entry). Each probability entry has a name that the table user uses to find the probability value it is interested in and the value itself (a real number between
0.0 and 1.0.) The ballistic gun looks for the probability entry with the name “prob- ability”.
For ranges that are greater than the last specified range, the probability is zero.
The range for missiles is the range from the missile to the target, not from the entity that fired the missile.
coefficients – a coefficient probability list is a list of coefficient probability entries. Each entry has a probability name and the coefficients of a standard polynomial that can be used with a given range to determine the specified probability. The order of the polynomial is determined by the number of coefficients provided. For example, an entry of:
(probability -5.00000E-008 -300000E-012 1.0000)
indicates that the formula to use for a given range r would be:
(-5.00000E-008 * r2) + (-300000E-012 * r) + 1.0
Values calculated will be constrained to be between 0.0 and 1.0. Zero values are factored out, for example:
(probability -5.00000E-008 0.0000 1.0000)
indicates that the formula to use for a given range r would be:
(- 5.00000E-008 * r2) + (0.0 * r) + 1.0
The following is an example of the M1A2MainGun.hit hit probability table:
(hit-probability-table (entity-range
(entity-type 1 1 -1 -1 -1 -1 -1) (range-determinant
(range-list
(range 1000.000000
(probability 0.90000)
)
(range 2000.000000
(probability 0.8000)
)
(range 3000.000000
(probability 0.75000)
)
(range 4000.000000
(probability 0.70000)
)
)
)
)
)
For the damage-by-power damage system, VR-Forces has damage probability tables for each power type. For more information, please see “Configuring the Damage File for Damage-By-Power,” on page 72-22.
For the damage-by-ammo-type damage system, VR-Forces has damage probability tables for direct fire and collateral damage. A munition type does not need to have both types of probability table if one of the types is not appropriate. For example, an M16 does not have a collateral damage file. Conversely, an artillery shell does not have a direct fire probability table. For more information, please see “Configuring Damage for Damage-by-Ammo-Type,” on page 72-26.
Direct flight. Missiles fly directly to a target. Accuracy is controlled by their maneu- verability parameters.
Laser guided. Missiles follow a laser designator to the target. If the laser is blocked or disrupted, the missile goes to the last known location of the target.
Route following. Some missiles, such as cruise missiles, can follow a route to a target and detonate either at the target or at a proximity to the target.
The range for missiles is the range from the detonation location to the target, not from the entity that fired the missile.
The missile launcher for direct flight missiles works as follows:
The weapon system’s controller passes the target type to its ammo select table to find the right resource for that target type.
The missile resource is returned and the system loads the missile to fire.
The entity tries to acquire the target. It sends the desired rotation angle and eleva- tion to acquire the target to the rotating mount actuator and elevation mount actu- ator.
Actuators move according to their slew rate speeds and send how far they went in a tick back to the weapon launcher so it can recalculate the remaining amount. It also publishes the articulated part numbers along with amount of rotation/elevation to the network.
When the feedback has us reach our max angle off boresight, we can fire on the target. The missile object is created.
The launcher actuator sends a fire interaction.
Configuring Weapon Systems and Munition Damage — Configuring Missile Systems
Parameters in the missile launchers system definition file affect whether or not it fires. The following code is from ./data/simulationModelSets/Enti- tyLevel/vrfSim/systems/weapons/fixed-marverick-missile-launcher.sysdef:
(controllers
(missile-launcher-control
...
(max-vehicle-speed-to-fire 500.000000)
(max-azimuth-angle-off-boresight 1.570000)
(max-elevation-angle-off-boresight 1.570000) (preload-weapon True)
(load-ammo-time 1.000000)
(unload-ammo-time 0.000000)
...
)
)
When the missile is created, it flies as follows:
Using the missile’s movement parameters, the missile controller (track-entity if the target is an entity, or target-point if the target is a location) determines the values to be sent to the missile-maneuver actuator.
The missile-collision actuator then checks to see if the missile is going to collide with the terrain or an entity. If so it sends out a detonation interaction.
Missile parameters affect how it detonates. The following code is from ./data/simula- tionModelSets/EntityLevel/vrfSim/systems/weapons/missile-warhead.sysdef:
(actuators (warhead
...
(detonate-on-ground-impact True) (detonate-on-water-impact True) (detonate-on-entity-impact True) (allow-direct-hit True)
...
)
)
The missile launcher for laser guided missiles works as follows:
The target selection controller chooses the best target for the weapon system and passes it to the weapon through the weapon’s weapon-interface.
The weapon system’s launcher controller tells the lasing controller the targets.
The lasing controller looks for an actively lased target that matches the lasing code. If there are no lased targets, it checks to see if it can autonomously lase. If it can, it starts to lase the target.
Once the launcher controller has a lased target, it tells the movement system to rotate to the target.
Once it is created, a laser-guided missile flies as follows:
Configuring Weapon Systems and Munition Damage — Configuring Indirect Fire Weapons
When a simulation object receives an indirect fire task, its indirect-fire-controller queues the task and checks for availability of an indirect fire weapon. It continues to check until a weapon becomes available. Then it sends the fire task to the weapon through the indirect weapon interface. If a task requires multiple weapons, the indirect- fire-controller continues this process until the task is complete. (The indirect-fire- controller and indirect weapon interface are analogous to the target-select-controller and weapon interface described for direct fire weapons.)
When an indirect-fire-weapon-controller gets a task, it reads the fire mission from the indirect weapon interface. The indirect fire weapon controller tries to align the turret and load the munition. When the weapon is ready to fire, it passes the information to its indirect-fire-actuator.
Figure 72-2 illustrates this process.
Simulation Object
indirect-fire-controller (from OPE file)
Weapon system
indirect-fire-weapon-controller
indirect-fire-weapon-controller
indirect-fire-actuator
indirect-fire-actuator
munition
fire interaction
munition
fire interaction
Configuring Weapon Systems and Munition Damage — Configuring Indirect Fire Weapons
Examples of indirect fire weapons include the M284-155mm cannon (./data/simula- tionModelSets/EntityLevel/vrfSim/systems/weapons/M284-155mm-cannon.sysdef), the M252-81mm mortar (M252-81mm-mortar.sysdef), and MK45 naval gun (./data/simu- lationModelSets/EntityLevel/vrfSim/systems/weapons/MK45NavalGun.sysdef). Also, although hand grenades would not normally be thought of as indirect fire weapons, the hand grenade tasks call the fire for effect tasks. Therefore, they use the same controllers and actuators as indirect fire weapons.
The munitions used by the indirect fire weapon systems are configured with explosive power in detonationParams.mtl. Therefore simulation objects that are susceptible to explosive power can be damaged by them. Their damage system definition files will point to the appropriate damage table files to assess damage from these munitions.
As with other weapon systems, the system definition files for indirect fire weapons have parameters that control when they can be used an how effective they are. For example, they have minimum and maximum ranges, as shown in this snippet from the cannon- controller in M284-155mm-cannon.sysdef:
(load-ammo-time 15.000000)
(unload-ammo-time 5.000000) (default-ammo-list
(m107 "M107-155mm")
)
(num-rounds-per-mission 5)
(min-range 2000.000000)
(max-range-list 5000.000000 10000.000000 15000.000000 20000.000000
25000.000000 30000.000000)
(range-name "M284-15mm Cannon")
The following snippet is from the M284-cannon actuator in the same system definition file:
(projectile-start-speed 0.000000)
(muzzle-offset 6.090000 0.000000 0.000000)
(probable-error-in-range 15.000000)
(probable-error-in-displacement 4.000000)
(probable-error-in-burst-height 5.000000) (simulate-munition True)
Configuring Weapon Systems and Munition Damage — Configuring Fixed Weapons
Fixed munitions, such as mines and IEDs can be triggered in the following ways:
Immediately, by a detonate message.
By proximity of a valid target. The weapon needs a sensor system or a proximity controller that can detect targets.
Timed detonation, from when the system is armed.
Fixed munition have a detonation controller. The detonation controller processes set detonation messages to determine how it is to be triggered and whether or not it is armed. It tells the warhead-detonation-actuator when to arm the weapon. For imme- diate and timed detonation, it tells the warhead actuator to detonate the device.
VR-Forces has two types of fixed weapons, naval mines and IEDs.
IEDs are simulation objects that have an explosive device system (./data/simulationMod- elSets/EntityLevel/vrfSim/systems/weapons/explosive-device.sysdef). These objects need a sensor to detect targets. The Roadside IED object has a visual sensor. The detonate controller lists the object types to detect:
(fuse-type "Proximity Fuse")
(detonation-proximity-distance 2.000000) (armed True)
(object-types-to-detect
(object-type 1 (1 -1 -1 -1 -1 -1 -1))
(object-type 1 (3 -1 -1 -1 -1 -1 -1))
(object-type 1 (5 -1 -1 -1 -1 -1 -1))
)
Naval mines use the ./data/simulationModelSets/Enti- tyLevel/vrfSim/systems/weapons/naval-mine-explosive-device.sysdef system definition file. It has a proximity sensor build into the system definition, so it does not need an external sensor to detect targets. The detonate controller does not list the object types to detect:
(fuse-type "Proximity Fuse")
(detonation-proximity-distance 25.000000) (armed True)
(object-types-to-detect )
However, the proximity sensor component does list object types to detect:
(default-proximity 150)
(detect-only-hostile-forces True) (object-types-to-detect
(object-type 1 (1 3 -1 -1 -1 -1 -1))
(object-type 1 (1 4 -1 -1 -1 -1 -1))
)
Configuring Weapon Systems and Munition Damage — Calculating Damage from Munitions
The bomb-bay weapon system releases bombs in response to Release Bomb tasks. Bombs can drop directly onto targets or be laser guided. Once a bomb is released, it uses the ./data/simulationModelSets/EntityLevel/vrfSim/systems/movement/smart-bomb- dynamics.sysdef movement system to control movement. It has a warhead actuator that is similar to the warhead actuator in missiles. Its ability to navigate toward and hit its target is controlled by parameters that you can set in the Simulation Object Editor. For details, please see “Release Bomb Tasks,” on page 28-18.
VR-Forces has the following ways to calculate damage:
Damage-by-power. Each munition is configured for its power in the explosive, kinetic, fragmentation, and armor-piercing domains as appropriate. (You can add new domains without writing code.) Damage systems (.sysdef files) reference the damage files (.dmg) for the type of munition power that can affect simulation objects that use the system. Damage files configure the amount of damage that occurs when different levels of power are applied. The damage-by-power model is used for all entity-level simulation objects in VR-Forces 4.5 and later and is the preferred method for calculating damage.
Damage-by-ammo-type. Each munition that can affect a simulation object is configured individually in the damage system used by that object and refers to a damage file that is specific to that type of munition. This model was used in VR- Forces 4.4.2 and earlier. It is supported in VR-Forces 4.5 and later.
The damage-by-power method of configuration makes it much easier to add new munitions than damage-by-ammo-type. You add the munition to one file and the generic power calculations in the damage files translate the power of the munition to damage. However, if you have specific requirements for the effects of a munition on different simulation objects, you can use the damage-by-ammo-type method in conjunction with damage-by-power. If VR-Forces finds an ammo-entry block in the damage system file, it uses that entry and its related damage file for that ammo type instead of the damage-by-power damage file that would otherwise be used.
For more information, please see “Configuring Damage-by-Power,” on page 72-18 and “Configuring Damage-by-Ammo-Type,” on page 72-25.
In the damage-by-power method of calculating damage, each munition has a detonation-power-entry block in ./data/simulationModelSets/base/detonation- Params.mtl. The following is the entry for the 7.62 mm bullet:
(detonation-power-entry (munition
;; 7.62 mm
(munition-type 2 8 222 2 2 -1 -1)
(warhead -1)
(guidance-mode 0)
)
(power-list (kinetic
(direct 2.24) ;; Kilojoules
)
)
The munition block identifies the munition type using the DIS/RPR FOM object enumeration. (The default configuration does not use the warhead or guidance-mode parameters.)
The power-list block is a list of domains and the configuration for a determinant that produces a power value based on an input range. In this example, the 7.62 mm shell has power in the kinetic domain.
The default configurations support the following domains:
Explosive. Munitions that affect simulation objects within some range of the deto- nation. Explosive munitions represent power in kiloPascals (kPa) of incident pres- sure.
Kinetic. Munitions that directly strike a simulation object. Kinetic munitions represent power in kilojoules (kJ) of energy.
Armor-piercing. Munitions that strike an armored object and penetrate it. Armor piercing munitions represent power in millimeters of penetration.
Fragmentation. Explosives that cause damage by fragmenting, such as grenades.
You can add other domains without writing code. For details, please see “Adding a New Power Type,” on page 72-23.
The power values used in the default configuration are based on publicly available information about the power of the various types of munitions and the values used try to be consistent in their relative power.
To determine the power of a detonation at a specific location a power determinant must be defined. The determinant maps a range value to a power value. Range can have different possible meanings, depending on how the range-from parameter is defined for the determinant. If range-from is undefined, impact-point is assumed unless the determinant does not support this setting.
If range-from is impact-point the determinant determines power based on the range from the impact point of the detonation to some other location in the vicinity. This is used for the explosive and fragmentation domains, but could be used for any power that has some area of effect (for example, perhaps shrapnel or incendiary damage). This is equivalent to collateral damage as defined in the damage-by-ammo-type damage system.
Example (from detonationParams.mtl):
(detonation-power-entry (munition
;; 85 mm HEAT
(munition-type 2 2 222 2 8 1 -1)
(warhead -1)
(guidance-mode 0)
)
(power-list (explosive
(range-from "impact-point") (range-list
(range 3.5
(power 70.0)
)
(range 4.6
(power 40.0)
)
(range 5.7
(power 27.5)
)
...
(range 35.0
(power 2.4)
)
)
)
(kinetic
(range-from "shooter-to-impact")
(range-coefficients -2.6600E-004 0.0000 5319.0)
)
(armor-piercing
(range-from "shooter-to-impact")
(range-coefficients -9.0000E-006 0.0000 180.0)
)
)
)
If range-from is shooter-to-impact (as in the previous example), the determi- nant determines power based on the range from the entity that fired the round to the point of impact. Any points outside of the point of impact are not affected by the detonation. This is used for the kinetic and armor-piercing domains, but could be used for any power that is directed at a particular target and has no area of effect. This is equivalent to direct damage as defined in the damage-by-ammo-type damage system.
If range-from is unused the determinant determines power without using the input range. This is used by the direct determinant, which ignores the range-from setting completely. (For more information, please see “Determinant Types,” on
page 72-20.)
If range-from is shooter-and-impact-point the determinant determines power based on both the range from the shooter and from the impact point. This option is not implemented by VR-Forces.
The range-coefficients determinant calculates the power based on a series of coeffi- cients. Configuring coefficients works exactly the same way as the hit probability coefficients, except that the output value can be any number 0 or greater, not just a probability for 0.0 to 1.0. (For details about hit probability, please see “Hit Proba- bility Tables,” on page 72-9.) For example:
(kinetic
(range-from "shooter-to-impact")
(range-coefficients -1.3000E-003 0.0000 26005.0)
)
The range-list determinant determines the power based on a step function. This is configured exactly the same way as the hit probability range-list, except that the output value can be any number 0 or greater, not just a probability for 0.0 to 1.0. For example:
(explosive
(range-from "impact-point") (range-list
(range 4.5
(power 70.0)
)
(range 6.0
(power 40.0)
)
...
(range 47.0
(power 2.4)
)
)
)
The direct determinant always produces the same power at the point of impact, regardless of the range from the shooter. It produces no power at any range from the point of impact. As a result, the range-from setting is ignored, because the range input is unused. For example:
(kinetic
(direct 272.873) ;; Kilojoules
)
Entity damage is configured through the system definition files and the damage files they reference. A system definition file configures power in the damage-by- munition-power block.
The system definition files provided with VR-Forces have a damage-model block. However none of the files provided use this block. It is available for customers who want to configure munitions using the damage-by-ammo-type method. It also enables backwards compatibility with old SMSs. For information about using the damage- model block, please see “Configuring Damage-by-Ammo-Type,” on page 72-25.
A system definition file can define any number of damage-by-power-entry items, each for a different power-type. This is the damage domain of the power. To add a new type of power, add new settings in detonationParams.mtl and in the system definition files for simulation objects that need to be damaged by this effect.
Each damage-by-power-entry specifies a damage file that defines how a power value maps to a damage probability. (Damage files are in ./data/simulationModelSets/Enti- tyLevel/vrfSim/damage.) The comments in the damage file indicate the unit of measure- ment for power.
The following example is from ./data/simulationModelSets/Enti- tyLevel/vrfSim/systems/damage/ground-heavy-armor.sysdef:
(damage-by-munition-power (damage-by-power-entry
(power-type "explosive") (damage-file
(filename "$(damage-dir)\heavy-armor-explosive.dmg")
)
)
(damage-by-power-entry (power-type "kinetic") (damage-file
(filename "$(damage-dir)\heavy-armor-kinetic.dmg")
)
)
(damage-by-power-entry
(power-type "armor-piercing") (damage-file
(filename "$(damage-dir)\heavy-armor-armor-piercing.dmg")
)
)
)
(damage-model )
It shows that simulation objects that use the ground-heavy-armor.sysdef system defintion file can be damaged by explosive, kinetic, and armor piercing power.
Damage files configure damage based on the side of the bounding volume being affected. The damage actuator delivered with VR-Forces uses surfaces of front, rear, left-side, right-side, bottom, and top (other components could model the entity’s geom- etry differently, and therefore use different surface strings). A surface entry has a list of angle-of-incidence entries. An angle-of-incidence entry has an angle (in radians).
The determinant block specifies the damage. The determinant can be a step- function or a list of coefficients. Each determinant can specify probabilities for cata- strophic-kill, mobility-kill, firepower-kill or some combination of them.
The ground-heavy-armor.sysdef file has a parameter called round-down that indicates what probabilities should be used when the input power value is between two steps. For power we want to round down to the next lower power (and lesser probability). There- fore round-down is set to 1 (true) for all damage files. If this parameter is not specified, the step function rounds up.
The following code, which uses the step-function determinant, is from
./data/simulationModelSets/EntityLevel/vrfSim/damage/heavy-armor-explosive.dmg:
(damage-table (front
(angle-of-incidence (angle 1.570800) (determinant
(step-function (round-down 1)
(power 7.5
(catastrophic-kill 0.1)
)
(power 12.5
(catastrophic-kill 0.5)
)
(power 20.0
(catastrophic-kill 0.6)
)
(power 45.0
(catastrophic-kill 0.75)
)
(power 70.0
(catastrophic-kill 0.99)
)
)
)
)
)
...
)
The following code, which uses the coefficients determinant, is from ./data/simu- lationModelSets/EntityLevel/vrfSim/damage/missile-explosive.dmg:
(damage-table
...
(left-side
(angle-of-incidence (angle 1.5708) (determinant
(coefficients
(catastrophic-kill 0.02 -0.4)
(firepower-kill 0.022 -0.44)
(mobility-kill 0.025 -0.5)
)
)
)
)
...
)
To add a new type of power, you add it to the relevant munitions in detonation- Params.mtl and then add it to the appropriate damage system. For example, suppose you want to model the effects of the heat generated by a munition. You could add thermal power. For the sake of this example, suppose that an 85mm HEAT round has thermal power. To add thermal power, you would have to do the following:
Add the new power to the detonation-power-entry, as follows:
(detonation-power-entry (munition
;; 85 mm HEAT
(munition-type 2 2 222 2 8 1 -1)
(warhead -1)
(guidance-mode 0)
)
(power-list (explosive
(range-from "impact-point") (range-list
(range 3.5
(power 70.0)
)
...
)
)
(kinetic
(range-from "shooter-to-impact")
(range-coefficients -2.6600E-004 0.0000 5319.0)
)
(armor-piercing
(range-from "shooter-to-impact")
(range-coefficients -9.0000E-006 0.0000 180.0)
)
(thermal
(range-from "impact-point") (range-list
(range 3.5
(power 70.0)
)
...
)
)
)
)
You would have to determine the unit of heat that you wanted to use to measure its effect and come up with realistic power levels at different distances.
In the damage systems for the simulation objects that can be affected by thermal power, add a damage-by-power entry. Suppose that you want lifeforms to be damaged by thermal power. You would update the lifeform-default.sysdef file as follows:
(damage-by-munition-power (damage-by-power-entry
(power-type "explosive") (damage-file
(filename "$(damage-dir)\lifeform-explosive.dmg")
)
)
(damage-by-power-entry (power-type "kinetic") (damage-file
(filename "$(damage-dir)\lifeform-kinetic.dmg")
)
)
(damage-by-power-entry (power-type "thermal") (damage-file
(filename "$(damage-dir)\lifeform-thermal.dmg")
)
)
)
Create a damage file called lifeform-thermal.dmg. Configure it similarly to other damage files.
To configure damage-by-ammo-type, you add an ammo-entry to the damage- model block of the damage system system definition file (.sysdef) for each type of ammunition that you want a simulation object using that system definition to be vulnerable to. Then, you create a damage table (.dmg) for the type of damage that you can take.
The following code is from vrforces4.4.2/data/simulationModelSets/Enti- tyLevel/vrfSim/systems/damage/lifeform-default.sysdef.
(damage-model (ammo-entry
(ammo
;;Ballistic anti-air munitions-- 20-30mm HE cannon (munition-type 2 1 -1 2 -1 -1 -1)
(warhead -1)
(guidance-mode 0)
)
(direct-damage-file
(filename "$(damage-dir)\light-armor-vs-explosive-round.dmg
)
(collateral-damage-file
(filename "$(damage-dir)\collateral-gnd-PG7.dmg")
)
)
(ammo-entry (ammo
(munition-type 2 2 222 1 8 -1 -1)
(warhead -1)
(guidance-mode 0)
)
(direct-damage-file (filename "")
)
(collateral-damage-file
(filename "$(damage-dir)\gnd-TOW.dmg")
)
)
...
)
These entries specify two munition types that lifeforms are vulnerable to (anti-air munitions and TOW missiles). In the case of ballistic anti-air munitions, they can take collateral damage and direct damage. In the case of TOW missiles they can take collat- eral damage.
Configuring Weapon Systems and Munition Damage — Configuring Damage-by-Ammo-Type
As in damage-by-power, damage files for damage-by-ammo-type configure damage based on the side of the bounding volume being affected. The damage actuator deliv- ered with VR-Forces uses surfaces of front, rear, left-side, right-side, bottom, and top (other components could model the entity’s geometry differently, and therefore use different surface strings). A surface entry has a list of angle-of-incidence entries. An angle-of-incidence entry has an angle (in radians).
A surface entry has a range-determinant. The entry is intended for use with angles of inci- dence that go from the previous entry’s specified angle to the current one (or in the case of the first entry, from 0.) The range determinant is exactly the same as the range deter- minant described in “Hit Probability Tables,” on page 72-9.
The damage actuator provided by MAK looks for a probability entry with the name
catastrophic-kill, mobility-kill, or firepower-kill.
The following code is a portion of the damage table from vrforces4.4.2/data/simulation- ModelSets/EntityLevel/vrfSim/damage/light-armor-vs-explosive-round.dmg.
(damage-table (front
(angle-of-incidence
(angle 0.5236) ;; 30 degrees (range-determinant
(coefficients
(catastrophic-kill -5.0000E-008 0.0000 1.0000)
)
)
)
(angle-of-incidence
(angle 1.0472) ;; 60 degrees (range-determinant
(coefficients
(catastrophic-kill -5.0000E-008 0.0000 1.0000)
)
)
...
)
...
)
The following code is a portion of the damage table from vrforces4.4.2/data/simulation- ModelSets/EntityLevel/vrfSim/damage/collateral-gnd-PG7.dmg.
(damage-table (front
(angle-of-incidence
(angle 0.5236) ;; 30 degrees (range-determinant
(range-list (range 1.000000
(catastrophic-kill 0.900000)
)
(range 2.000000
(catastrophic-kill 0.750000)
)
(range 5.000000
(catastrophic-kill 0.600000)
)
(range 10.000000
(catastrophic-kill 0.450000)
)
(range 15.000000
(catastrophic-kill 0.050000)
)
)
)
...
)
...
)
Configuring Weapon Systems and Munition Damage — Configuring Damage for Dynamic Ter- rain
Dynamic terrain damage is configured using the damage-by-power approach. It is configured in ./data/simulationModelSets/base/vrfSim/systems/other/dynamic-terrain.sysdef in the settings for the dynamic-terrain-munition-damage controller. Terrain can be damaged using standard terrain damage or high fidelity terrain damage.
When you use standard terrain damage, the controller publishes a series of concentric damage areas of decreasing damage from the impact point. The type of terrain damage (that is, the switch in the terrain to be updated) is defined by standard-terrain-damage-type in dynamic-terrain.sysdef. The detonation power domain that causes this damage is defined by standard-power-type. The standard-terrain-damage-table block specifies the concentric areas. When a detonation is received, for each entry in this table a new area is created based on the range that produces the specified power. Then the switch in the terrain model is set to the specified damage setting.
The following code is from ./data/simulationModel- Sets/base/vrfSim/systems/other/dynamic-terrain.sysdef:
(standard-terrain-damage-table (damage-by-power-entry
(power 7)
(damage "1")
)
(damage-by-power-entry (power 15)
(damage "2")
)
(damage-by-power-entry (power 60)
(damage "3")
)
)
This table generates three dynamic terrain areas. The smallest area is defined by the area on the terrain that experiences an explosive power of at least 60. It is switched to a value of “3”. The next larger area is the area that experiences power between 15 and 60. It is switched to a value of “2”. Finally the outer area is the area that experiences power between 7 and 15. It is switched to a value of “1”.
Configuring Weapon Systems and Munition Damage — Configuring Damage for Dynamic Ter-
rain
You can configure high fidelity damage areas along with the standard damage. To deter- mine where high fidelity damage areas should be created, VR-Forces queries the terrain to find any dynamic terrain features that match the given dynamic-terrain-type setting.
This can be used to generate additional or more specific types of damage to select loca- tions in the terrain that support a higher fidelity of damage. Just as with standard damage, a power-type is specified that corresponds to the detonation power domain that is causing this damage. High fidelity terrain damage is configured in the high- fidelity-terrain-damage-table block. It has the same format as the standard-terrain-damage-table.
The high fidelity damage lets you specify the damage-algorithm used. VR-Forces only supports the range-based algorithm, but you can develop your own algorithms in a plug-in. If you add additional damage algorithms, they might require configuration options that are not supported in the high-fidelity-damage-table provided by MAK. If necessary, you can specify additional parameters using the additional-algorithm- config parameter, which accepts a list of key/value string pairs.
High fidelity damage can produce a secondary detonation. This can be specified by setting detonation-on-destroy to True and defining the detonation-munition parameter. The delay parameter defines a delay in seconds between when power was first experienced and when the damage should be done. This allows the secondary detonation to create a particle effect that can mask the underlying terrain switch.
The following code is from ./data/simulationModel- Sets/base/vrfSim/systems/other/dynamic-terrain.sysdef:
(high-fidelity-terrain-damage-table (entry
(dynamic-terrain-type "damage_house") (power-type "explosive")
(damage-algorithm "range-based") (delay 2.0)
(detonate-on-destroy True) (detonation-munition 2 0 0 4 2 0 0) (terrain-damage-table
(damage-by-power-entry
(power 7) ;; explosive power is in kPa (damage "1")
)
(damage-by-power-entry (power 15)
(damage "2")
)
(damage-by-power-entry (power 60)
(damage "3")
)
)
(additional-algorithm-config
;; Additional key/value pairs (string values) can be added here for
;; custom algorithm configuration
;; For example:
;; (my-custom-algorithm-config "config value string")
)
)
)
This section has two examples of how to configure a direct fire weapon. The first uses the damage-by-power method. The second uses the damage-by-ammo-type method.
This section describes the files that work together to define an M240 machine gun and allow it to fire on and damage entities. Figure 72-4 illustrates the relationships between the files. (The lines of code are not in context. They are the minimum needed to show the connections between the files.)
M240-7_62mm-mach-gun.sysdef
(entity-priority
(entity-type 3 1 -1 -1 -1 -1 -1))) (NATO-7.62x51mm)
(hit-probability-file (filename $(hit-dir)\M2.hit))
(allowed-state-repository-types "ground-vehicle-param" "rotary-wing- entity-param")
detonationParams.mtl (detonation-power-entry
;; 7.62 mm 
(munition (munition-type 2 8 -1 2 2 -1 -1))) (power-list
(kinetic (direct 2.24) ;; Kilojoules)))
M240.asl
(target-type 3 -1 -1 -1 -1 -1 -1) (NATO-7.62x51mm
(munition-type 2 8 225 2 2 5 0)
lifeform-default.sysdef
(damage-by-power-entry (power-type "kinetic")
(damage-file (filename "$(damage-dir)\lifeform-kinetic.dmg”))
M2.hit
(entity-type 3 -1 -1 -1 -1 -1 -1)
lifeform-kinetic.dmg damage-table
Lines indicate relationships between configuration file parameters and files.
Figure 72-3. Anatomy of a weapon system using damage-by-power
The M240 machine gun is configured in ./data/simulationModelSets/Enti- tyLevel/vrfSim/systems/weapons/M240-7_62mm-mach-gun.sysdef. Most of the file speci- fies the various components of the system that make it work. We are interested in the lines that help it connect to other files.
In the following code snippet, the allowed-state-repositories-types parameter specifies that ground vehicles and rotary-wing entities can use this system.
(meta-data
(system-name "M240 Machine Gun")
(system-description "Vehicle mounted M240 7.62mm Machine Gun. Typical secondary gun on tanks such as the M1A2. Targets lifeforms and unarmored vehicles.")
(allowed-state-repository-types "ground-vehicle-param" "rotary-wing- entity-param")
(system-categories "weapon")
The resources section specifies the type of ammunition this weapon uses.
(resources
(NATO-7.62x51mm
...
)
The targeting control section specifies the entity types that this system can fire at — humans and several types of ground vehicles. Note that wildcards are used for entity types.
(targeting-control (target-priorities
(entity-priority
(entity-type 3 1 -1 1 1 -1 -1)
(priority 2)
)
(entity-priority
(entity-type 3 1 -1 -1 -1 -1 -1)
(priority 2)
)
(entity-priority
(entity-type 1 1 -1 7 -1 -1 -1); large trucks
(priority 3)
)
...
)
)
Finally, a ballistic direct fire weapon system system definition file specifies a hit file for the munition it uses. The hit file specifies the probability that targets will get hit by the munition.
(main-gun-joy
(component-descriptor-type "ballistic-gun-descriptor")
...
(velocity-affects-hit-chance False) (hit-probability-file
(filename "$(hit-dir)\M2.hit")
)
(range-name $display-name (default "M240 MG")) (start-with-tracers true)
)
Although this section shows code snippets from the system definition file, we recom- mend that you edit systems in the OPD Editor.
When an entity with an M240 machine gun detects a target, it must choose the correct ammunition for that target. This is specified in the ammo select file. The ammo select file for the M240 is ./data/simulationModelSets/EntityLevel/vrfSim/ammoselect\M240.asl.
The file has entries like the following:
(lifeform ;; matches any lifeform (target-type 3 -1 -1 -1 -1 -1 -1) (ammo
(NATO-7.62x51mm ;; these names need to match resource names (munition-type 2 8 225 2 2 5 0)
(tracer-type 2 8 225 2 2 4 0) ; Ball/tracer mix, 4:1
(warhead 0)
)
)
)
There is an entry for each of the target types in M240-7_62mm-mach-gun.sysdef. If you specify a target type in a weapon system definition file and do not have a corresponding entry in an ammo select file, the weapon will not know what kind of ammunition to use for that target type and will not fire on it.
For each target, it specifies the entity type for the munition and tracer bullet.
Weapon systems that fire autonomously, such as the main guns on tanks, machine guns, and missiles, need an ammo select file. Some weapons, such as artillery and naval guns, do not need an ammo select file because they only fire when tasked by users or in a plan, and the choice of munition is one of the task parameters.
As noted in previous sections, the M240 gun uses a 7.62 mm munition. The detona- tionParams.mtl file specifies that a 7.62 mm munition has kinetic power.
Each simulation object has a damage system. The M240 can target lifeforms. Most life- forms use the Default Armor damage system. It is configured in ./data/simulationModel- Sets/EntityLevel/vrfSim/systems/damage/lifeform-default.sysdef. This file uses the damage- by-power configuration. It specifies that a lifeform can be damaged by explosive power and kinetic power.
(damage-by-munition-power (damage-by-power-entry
(power-type "explosive") (damage-file
(filename "$(damage-dir)\lifeform-explosive.dmg")
)
)
(damage-by-power-entry (power-type "kinetic") (damage-file
(filename "$(damage-dir)\lifeform-kinetic.dmg")
)
)
)
Since the M240 machine gun fires a munition that has kinetic power, if a lifeform is attacked by this munition, VR-Forces looks at the lifeform-kinetic.dmg damage file to calculate damage.
A hit file specifies the probability that a simulation object will be hit by a type of muni- tion at various distances. The hit file specified by the M240 system definition is M2.hit. It has an entry for each simulation object type that can be struck by this munition type. The following code snippet is the entry for human entities.
(entity-range
(entity-type 3 -1 -1 -1 -1 -1 -1) (range-determinant
(range-list
(range 10.000000
(probability 1.00000)
)
(range 200.000000
(probability 0.80000)
)
(range 500.000000
(probability 0.4000)
)
(range 1000.0
(probability 0.2)
)
(range 3600.000000
(probability 0.100)
)
)
)
)
For more information about hit files, please see “Hit Probability Tables,” on page 72-9.
Based on the side of the entity that is hit, the angle it is hit at, and the range of the munition, the damage file specifies the type of damage caused.
For more information about damage files, please see “Damage Probability Tables,” on page 72-10.
This section describes the files that work together to define an M240 machine gun and allow it to fire on and damage entities using the damage-by-ammo-type method. Figure 72-4 illustrates the relationships between the files. (The lines of code are not in context. They are the minimum needed to show the connections between the files.)
In the damage-by-ammo-type approach, the hit file, ammo select file, and weapon system file are the same as in the damage-by-power approach and will not be discussed in this section. The damage system system definition file is different, as is the damage file. The detonationParams.mtl file is not used.
M240-7_62mm-mach-gun.sysdef
(entity-priority
(entity-type 3 1 -1 -1 -1 -1 -1)
)
(NATO-7.62x51mm
$(hit-dir)\M2.hit
(allowed-state-repository-types "ground- vehicle-param" "rotary-wing-entity-param")
M240.asl
(target-type 3 -1 -1 -1 -1 -1 -1) (NATO-7.62x51mm
(munition-type 2 8 225 2 2 5 0)
lifeform-default.sysdef
(ammo
(munition-type 2 8 -1 2 -1 -1 -1) (filename "$(damage-dir)\rifle.dmg")
M2.hit
(entity-type 3 -1 -1 -1 -1 -1 -1)
rifle.dmg
damage-table
Lines indicate relationships between configuration file parameters.
Figure 72-4. Anatomy of a weapon system using damage-by-ammo-type
Each simulation object has a damage system. The M240 can target lifeforms. Most life- forms use the Default Armor damage system. For the damage-by-ammo-type approach, in VR-Forces 4.4.2 or earlier, it is configured in ./data/simulationModelSets/Enti- tyLevel/vrfSim/systems/damage/lifeform-default.sysdef. The damage system has a a damage-model block with an ammo-entry block for each type of ammunition that simulation objects that use the damage system are vulnerable to. The ammo entry can specify a damage file (.dmg) for direct hits and for collateral damage. The lifeform- default.sysdef includes the following ammo entry:
(damage-model
...
(ammo-entry (ammo
munition-type 2 8 -1 2 -1 -1 -1)
(warhead -1)
(guidance-mode 0)
)
(direct-damage-file
(filename "$(damage-dir)\rifle.dmg")
)
(collateral-damage-file (filename "")
)
)
The munition-type parameter uses wildcard values that match the munition type sent by the M240 machine gun (2 8 225 2 2 5 0). This means that a human entity that uses the Default Armor damage file can be damaged by a bullet fired by an M240 machine gun.
Based on the side of the entity that is hit, the angle it is hit at, and the range of the munition, the damage file specifies the type of damage caused.
For more information about damage files, please see “Damage Probability Tables,” on page 72-10.
73. Configuring Movement Systems
This chapter describes configuration files that affect simulation object movement.
Creating a User-Defined Formation 73-4
Configuring Obstruction Avoidance 73-4
Configuring Vector Feature Types 73-5
Configuring Movement Systems — Configuring Formations
Although you can create and edit formation files by hand as described in this section, the recommended way to create and edit formations is to use the Simulation Object Editor.
The object parameter database lists the formations available to a unit in the formations element in its .entity file. Each formation is identified by its name and the path to the formation file, for example:
<formations paramName="formation-list" autoLayout="0">
<formation formationName="Line" formationFile= "@(formation-dir)/platoonLine.frm"/>
<formation formationName="Column" formationFile= "@(formation-dir)/platoonColumn.frm"/>
<formation formationName="Wedge" formationFile= "@(formation-dir)/platoonWedge.frm"/>
<formation formationName="Vee" formationFile= "@(formation-dir)/platoonVee.frm"/>
</formations>
Configuring Movement Systems — Configuring Formations
A formation file specifies the name of the formation and has an entry for each simula- tion object in the default formation definition. Each entry specifies a promotion-id, a leader-promotion-id, and a position-offset, where:
The promotion-id specifies the order in which simulation objects are promoted to unit leader if the leader is incapacitated.
The leader-promotion-id specifies the unit member from whom the entry’s position will be offset.
The position-offset specifies how many meters behind, to the right, and above the entry will follow its leader. The position-offset is specified in terms of the body coor- dinate system of its leader.
The following is a portion of the formation file for a column formation:
(column-formation (entry-0
(promotion-id 0)
(leader-promotion-id -1)
(position-offset 0.000000 0.000000 0.000000)
)
(entry-1
(promotion-id 1)
(leader-promotion-id 0)
(position-offset -25.000000 0.000000 0.000000)
)
(entry-2
(promotion-id 2)
(leader-promotion-id 1)
(position-offset -25.000000 0.000000 0.000000)
)
(entry-3
(promotion-id 3)
(leader-promotion-id 2)
(position-offset -25.000000 0.000000 0.000000)
)
)
In a column, each simulation object follows the simulation object in front of it by 25 meters. Therefore, the leader-promotion-id for each entry is the promotion-id of the simula- tion object in front of it, and each entry has a position-offset of -25 meters.
The number of entries in a formation file is finite. However, it is possible to place more simulation objects into a unit than there are entries in a formation file. If this happens, VR-Forces increments the promotion-id of the last entry in the formation file and assigns the new simulation object the same position-offset as the last entry in the formation file. For a simple formation like a column, this works well. If you are using a more complex formation, this mechanism might create unintended relationships among simulation objects.
If you want to change the layout of the formations provided with VR-Forces, you can edit the formation files.
Configuring Movement Systems — Configuring Obstruction Avoidance
You can create formations other than those provided by VR-Forces. It is recommended that you create formations in the Simulation Object Editor. If you use the Simulation Object Editor, you do not have to edit any formation files or .entity files by hand.
To create a formation:
Using one of the formation files supplied with VR-Forces as your template, place as many entries as you want in the formation file and specify their offsets.
Save the new formation under a new name.
Add an entry to the formation list block in the .entity file for each unit that you want to be able to use the formation. Be sure to use the same structure and naming conventions as the default entries. For example:
<formations paramName="formation-list" autoLayout="0">
<formation formationName="Line" formationFile="@( formation-dir)/DI-companyLine.frm"/>
<formation formationName="Column" formationFile="@( formation-dir)/DI-companyColumn.frm.frm"/>
<formation formationName="Wedge" formationFile="@( formation-dir)/DI-companyWedge.frm"/>
<formation formationName="Vee" formationFile="@( formation-dir)/DI-companyVee.frm"/>
</formations>
We recommend that you configure your formations so that simulation objects follow the leader, rather than the next closest member of the formation (as is done in column formation.) This ensures that formations have the best chance of maintaining their formation as they maneuver.
You can configure ground entities to avoid specific entity types, vector features, or both.
The more vector feature types and entity types specified for avoidance, the more memory and processing power required.
Obstruction avoidance is influenced by the stopping-distance-factor and lateral-clearance parameters. If entities display erratic behavior, try raising the values, lowering the speed of the entities, or both.
Configuring Movement Systems — Configuring Obstruction Avoidance
To specify the types of objects that an entity type should avoid, add or remove the appropriate object type from the obstruction sensor entry in the movement system defi- nition file. For example, the following object types are configured for ground entities:
(object-type
(object-type 1 (18 -1 -1 2 -1 -1 -1)) ;; vrfObstacles object type
(object-type 1 (1 -1 -1 -1 -1 -1 -1)) ;; DtPlatform entity kind
(object-type 1 (3 -1 -1 -1 -1 -1 -1)) ;; DtLifeForm entity kind
)
Configuring avoidance of vector features relies on the attributes on the feature data as well as the named queries defined in ./appData/settings/featureconfig.txt. To configure specific feature data for obstruction avoidance, modify the feature-types-to-avoid type list in the obstruction sensor in the appropriate system definition file. The types in this file are named feature queries, and you can add as many as you need.
Example of human.sysdef:
(obstruction-sensor
...
(feature-types-to-avoid (type "MAK_OBSTACLE")
)
)
Example of air-cushion-default.sysdef. This entity specifically calls out building, infra- structure, and vegetation, instead of obstacle, because obstacle also includes waterway.
(obstruction-sensor
...
(feature-types-to-avoid (type "MAK_BUILDING")
(type "MAK_INFRASTRUCTURE") (type "MAK_VEGETATION")
)
)
Configuring Movement Systems — Configuring Embarkation
Entities and units that are configured to allow entities to embark on them have an occu- pancy-director-controller component. Its parameters configure embarkation, as follows:
The locations at which entities can embark on an entity are configured as ingress- points.
The locations from which entities can disembark are configured as egress-points.
The number of entities that can embark on an entity is defined by the embarkation- slots parameter.
The embarkation-slots parameter has one or more embarkation-slot-entry parameters that identify a location on the entity where an embarked entity can be placed. The embarka- tion-slot-entry parameters also specify the orientation of the embarked entity and the types of entities that can occupy the slot.
The ingress-points and egress-points parameters each have one or more load-entry parame- ters. The load-entry parameters specify one or more load-entry-point parameters. If there is one load-entry-point, an embarked entity enters the parent entity at that point and is immediately placed in an available slot. If a load-entry has multiple load entry points, they specify the points in a route that the embarking entity follows to reach its slot.
This configuration is for large parent entities, such as aircraft carriers, on which entities land and then taxi to a slot.
You configure embarkation in the Simulation Object Editor. For details, please see “Configuring Embarkation,” on page 65-34.
Configuring Emitters and Radios
This chapter describes configuration files for emitters and radios. For information about configuring the display of emitters, please see Chapter 84, Configuring Emitter Volumes.
Publishing Radio Transmitters 74-4
Configuring Emitters and Radios — Configuring Emitters
All fixed-wing aircraft have emitters as part of their radar sensor. Emitters have search modes. Search modes have a list of beams. You can configure entities with emitters that have more than one beam. You can also configure multiple emitters. The basic radar sensor with an emitter and two search modes (./data/simulationModel- Sets/<model_set>/vrfSim/systems/sensors/active-radar-sensor.sysdef) is as follows:
(active-radar-sensor-system (systems )
(sensors
(radar-sensor
(component-descriptor-type "radar-signature-sensor-descriptor") (component-type "radar-signature-sensor")
. . .
(sensor-domain "radar")
(sensor-offset $sensor-position) (sensor-positional-error 0.000000) (detection-level-determinator
(determinator-type "signature-detection-level-determinator") (detection-level-to-set-hostility 3)
(combat-identification-level-table-file
(filename "$(detection-dir)\std-radar-detection-table.csv")
)
)
(detection-period 0.000000) (publish-emitter-system True) (emitter-system
(system-name-enum 5570)
(system-function-enum 5) (radar-mode-list
(search-mode (index 0)
(radar-mode "Search") (beam-list
(beam-0 (index 0)
(type "track")
(frequency 4999999488.000000)
(frequency-range 10000.000000)
(power 70.000000)
(pulse-repetition-frequency 0.000000)
(pulse-width 0.000000)
(azimuth-center 0.000000)
(azimuth-sweep 0.523599)
(elevation-center 0.349066)
(elevation-sweep 0.523599)
(sweep-sync 0.000000)
(beam-function-enum 1)
(beam-param-index 0)
)
)
)
(track-mode (index 1)
(radar-mode "Track") (beam-list
(beam-0
Configuring Emitters and Radios — Configuring Emitters
...
)
)
)
)
)
)
)
To configure multiple emitters for an entity, add additional radar-sensor blocks. Each block must have a unique name. For example:
(radar-sensor-1
(component-descriptor-type "radar-signature-sensor-descriptor") (component-type "radar-signature-sensor")
. . .
(emitter-system
...
)
)
)
(radar-sensor-2
(component-descriptor-type "radar-signature-sensor-descriptor") (component-type "radar-signature-sensor")
. . .
(emitter-system
...
)
)
)
To add multiple modes on an emitter, add additional mode blocks to the radar mode list. The names of radar modes (for example, track-mode and search-mode) and the value for the radar-mode parameter are arbitrary. You can name them whatever you want.
To add multiple beams on a radar mode, add additional beam-list blocks and change the name of each block. For example:
(search-mode (index 0)
(radar-mode "Search") (beam-list
(beam-0
...
)
(beam-1
...
)
)
)
Configuring Emitters and Radios — Configuring Radios
All radios are DtVrfRadio classes or subclasses. The radio is responsible for managing incoming and outgoing radio messages on a single simulation object. Each radio is asso- ciated with a specific communication model, and uses this communication model to send and receive messages.
Radios are configured in platform (OPE) files. The radios block in the OPE file lists all the radios on the simulation object and the parameters for each radio. Parameters include the type of radio descriptor and type of radio class, which are strings used to create the C++ classes from the factories. The comm-model-name parameter identifies which communication model a radio is associated with. Every radio must be associated with a communication model.
A typical radio entry is as follows:
(main-radio
(radio-descriptor-type "radio-descriptor") (radio-type "default-radio")
(comm-model-name "default-radio-model") (publish-transmitter True)
(transmitter-params
(radio-type 7 1 225 2 1 20)
(initial-frequency 3000000.000000)
(power 30.000000)
)
)
Publishing radio transmitters is controlled by two parameters:
The publish-transmitters parameter in ./data/simulationModel- Sets/<model_set>/commModelParams.mtl. By default, this parameter is False for the simple communication model and True for the external communication model.
The publish-transmitter parameter in an entity’s OPE file. This parameter is set to true for all object types.
To publish radio transmitters, both of these parameters must be True. If you do not change the OPE files and set publish-transmitters to True, all simulation objects will publish radio transmitters. If you set publish-transmitters to True and do not want all simulation objects to publish radio transmitters, you can set publish-transmitter to False for the object types that you do not want to publish them.
This chapter explains how to configure joysticks and the keyboard to control entity movement.
Configuring Joysticks and Keyboard Control 75-2
Creating a Joystick Configuration 75-4
Mapping the Joystick Stick 75-6
Mapping Joystick Buttons and Keyboard Keys 75-7
Configuring “Switch Between” Options 75-10
Using Multiple Joysticks 75-13
Specifying a Favorite Joystick Configuration 75-14
You can control entity movement and weapon fire using a joystick, the keyboard, or both. You can attach multiple joysticks and can use a mix of joystick and keyboard control at the same time. You configure joystick and keyboard mappings on the Appli- cation Settings dialog box, Joystick Configuration page.
The controls available for configuration on the Joystick Configuration page are taken from the joystick controllers in the movement, gun, and other system definitions. For example, the ground-tracked.sysdef file has the following entry:
(joystick
(component-descriptor-type "joy-controller-descriptor") (component-type "ground-move-joystick-controller")
...
(joystick-controls (steering
(function-name "steering") (function-group $automotive-driving)
(description "Controls the steering of this entity") (min-value -1.0)
(max-value 1.0)
)
(throttle
(function-name "throttle") (function-group $automotive-driving)
(description "Controls the throttle of this entity") (min-value 0.0)
(max-value 1.0)
)
(brake
(function-name "brake")
(function-group $automotive-driving)
(description "Controls the braking of this entity") (min-value 1.0)
(max-value 1.0)
)
(change-gear
(function-name "change-gear") (function-group $automotive-driving)
(description "Puts the entity in forward, reverse or pivot gear") (min-value 0)
(max-value 2)
(cycle True) ;; Each click cycles from min to max
)
)
)
Based on this sysdef file, the Joystick Configuration page (Figure 75-1) has an Automo- tive Driving function with controls for brake, change-gear, steering, and throttle.
The min-value and max-value parameters determine how the edit buttons on the Joystick Configuration page work, as follows:
If min-value and max-value are both set to 1 (as in the brake control in the example system definition file), the control is a key mapping button ( ). You can set it to Yes or No.
If max-value is an integer greater than 1 (as in the change gear control in the example system definition file), the control is a key mapping button. You can configure keyboard buttons to increase or decrease the control by 1, or to set it to a specific value.
If min-value does not equal max-value and max-value is less than or equal to 1 (as in the throttle control in the example system definition file), there is a joystick button ( ) and a key mapping button on the Joystick Configuration page. The keyboard button lets you specify a percentage increase or decrease of the control value. (For example, increase throttle by 10%.)
A joystick configuration contains the joystick mappings and, optionally, keyboard mappings that you can use to control an entity. VR-Forces includes default configura- tions for a gamepad and a joystick.
To create a joystick configuration:
Create or open a scenario.
Choose Settings Application. The Application Settings dialog box opens.
Select the Joystick Configuration page (Figure 75-1).
Figure 75-1. Joystick Configuration page
Click the Add button ( ). The New Configuration dialog box opens.
Type a name for the configuration.
Click OK. The window redisplays to show the functions that this device can control (Figure 75-2).
Edit the joystick and keyboard mappings as described in “Mapping the Joystick Stick,” on page 75-6 and “Mapping Joystick Buttons and Keyboard Keys,” on page 75-7.
To control an entity with a joystick, you map the joystick controls to specific entity movement components and weapons.
To map joystick controls:
Create a joystick configuration, as described in “Creating a Joystick Configura- tion,” on page 75-4.
On the Joystick Configuration page (Figure 75-2), click the Joystick button ( ) for the function you want to map. A joystick configuration dialog box opens (Figure 75-3).
In the Controller list, select the controller you want to configure.
Configure each axis as follows:
To let VR-Forces select the axis, select the Detect option and move the joystick in the axis you want to use for this control.
To choose the axis, select the Select option and select an Axis from the list.
Move the joystick in the axis you are configuring. If the Maximum/Minimum slider moves in the direction that you expect, you are finished. If the slider moves opposite to what you expect, select the Reverse Axis check box. It should now move as expected.
Click OK.
Repeat this process for each function you want to control with the joystick.
You can map joystick buttons and keyboard keys to entity movement control and weapon control. When entity control is enabled, the entity control key mappings over- ride any other key mappings, such as observer control mappings.
To map joystick buttons and keyboard keys to entity control:
Create a joystick configuration, as described in “Creating a Joystick Configura- tion,” on page 75-4.
On the Joystick Configuration page (Figure 75-2), click the Key Mapping button ( ) for the control you want to map. A configuration dialog box opens. It may call for a range of values (Figure 75-4), or just be a toggle (Figure 75-5).
Figure 75-4. Key mapping configuration dialog box
If the mapping requires a range, for each row in the dialog box, do the following:
Click the Key Mapping button ( ). The Choose Control Button/Key dialog box opens (Figure 75-5).
Press the joystick button or keyboard key that you want to use to activate this control. It is displayed in the dialog box (Figure 75-6). (If a key binding is not available, the OK button does not become activated.)
Key Joystick button
Figure 75-6. Choose Control Button/Key dialog box with selection
Click OK.
In the Action column, select an option from the list.
In the Value column, enter an appropriate value for the Action option.
If the keyboard mapping is a toggle, The Choose Control Button/Key dialog box opens automatically. Do the following:
Press the key or joystick button that you want to use.
Click OK.
In the Repeat column, select Yes or No. Yes means that the action repeats if you hold down the key. No means it happens one time for each key press.
Click OK.
Repeat this process for each function you want to configure.
Some entities may have multiple systems of a certain type, such as weapons. You might want to be able to control all similar systems with the same set of keys and joystick controls. VR-Forces lets you do this with switch groups. You can specify a key or button to press to switch between the different systems in a switch group. For example, you might press a button to switch between a tank’s main battle gun and a machine gun.
The controls for which you can specify a switch between option are listed in the Switch Between section of the Joystick Configuration page. Specifying the key or button to use is described in “Mapping Joystick Buttons and Keyboard Keys,” on page 75-7. This section explains how to set up switch options.
To set up a switch option, when you define a function group in a system definition file’s meta data, you use the syntax switch_option:system. The switch_option is a keyword. If an entity has multiple systems that use that keyword, you can switch between them using the switch between key or button. VR-Forces systems use the weapon keyword for switching between weapon systems. The following code, from 120mm-gun.sysdef shows how this works.
The controllers specify two function groups for joystick control – $slew-group and
$ballistic-gun-group. These groups specify four functions that the joystick can control – slew, elevation, fire, and change ammo:
(weapon-120mm-gun (controllers
(turret-joystick
...
(joystick-controls (slew
(function-name "slew") (function-group $slew-group)
(description "Controls the slew of this weapon") (min-value -1.0)
(max-value 1.0)
)
)
)
...
(main-gun-control-joy (joystick-controls
(elevation
(function-name "elevation")
(function-group $ballistic-gun-group)
(description "Controls the elevation of this weapon") (min-value -1.0)
(max-value 1.0)
)
(fire
(function-name "fire")
(function-group $ballistic-gun-group) (description "Fires this weapon") (min-value 1.0)
(max-value 1.0)
)
(change-ammo
(function-name "change ammo") (function-group $ballistic-gun-group)
(description "Changes the ammo of this weapon") (min-value 1.0)
(max-value 1.0)
)
)
The meta-data section of the sysdef file specifies a value for these groups. It is specified as the keyword weapon followed by the name of the system – weapon:120mm Ballistic Gun:
(meta-data
(system-name "120mm Gun")
(system-description "Turreted 120mm gun, typical of tanks such as the M1A2. Fires M829A1-AP and M830-HEAT rounds. Targets ground vehicles.")
(allowed-state-repository-types "ground-vehicle-param") (system-categories "weapon")
(parameter-data-list
...)
(string-parameter-data (parameter-name "slew-group") (variable-type "DtRwString")
(display-label "Slew Joystick Group Name") (display-units "")
(source-units "")
(default-value "weapon:120mm Ballistic Gun")
)
(string-parameter-data
(parameter-name "ballistic-gun-group") (variable-type "DtRwString")
(display-label "Ballistic Gun Joystick Group Name") (display-units "")
(source-units "")
(default-value "weapon:120mm Ballistic Gun")
)
...
Other weapon systems are configured similarly. On the Joystick Configuration page (Figure 75-8), the Switch Between group lists weapon as an option. The weapons configured for switching all show the switch_option:sysdef syntax.
Figure 75-8. Switch between option
For details about using the switch between option, please see “Switching Between Systems,” on page 19-19.
You can attach multiple joysticks or game controllers to your computer. You must create a configuration for each joystick that you want to use. When you take control of an entity, you select the configuration you want to use and the functions that you want to control with the selected configuration.
In Figure 75-9, the selected entity (a helicopter) has two functions that can be controlled by joystick or game controller.
Figure 75-9. Take Control dialog box
You could select one configuration to control both, or you could control the two func- tions with different controllers, as follows:
Select the entity.
Choose Objects Take Control. The Take Control dialog box opens.
Clear the Rotary Wing Controls check box. This leaves the Gamepad configura- tion controlling the M230 ballistic gun.
Click OK.
Select the entity again and choose Objects Take Control. The Take Control dialog box opens (Figure 75-10). Only the Rotary Wing Controls function is avail- able, because the ballistic gun is already under the control of the Gamepad configu- ration.
Figure 75-10. Take Control dialog box, one function available
In the Configuration list, select a different configuration Figure 75-11.
Figure 75-11. Take Control dialog box, second configuration selected
Click OK. The rotary wing controls are now controlled by the Saitek configuration and the ballistic gun by the Gamepad configuration.
To specify a favorite joystick configuration:
Choose Settings Application. The Application Settings dialog box opens.
In the Game Controller Configurations list, select the configuration that you want to specify as the favorite.
Click the Star button ( ). A star is added to the configuration name in the list.
76. Attaching Components to Remote Entities
This chapter explains how to configure components on remote entities.
Attaching VR-Forces Components to Remote Entities 76-2
You can attach VR-Forces sensors, actuators, and controllers to remote (non-VR- Forces) entities. This feature allows you to add to the capabilities of the remote entity and better integrate it with the VR-Forces simulation. For example, you could add a radio to an entity or you could enable spot reporting. When you attach a component to a remote entity, you can write a plan for that entity that uses the attached components. For details, please see “Writing Plans for Remote Entities,” on page 36-39.
VR-Forces includes an example scenario, remoteAttachment, that uses remote attach- ment. Its use requires that you run an external application, the f18 example that comes with VR-Link. For details about how to run the scenario, please see the readme file in
./data/scenarios/remoteAttachment.
When you add a component to a remote entity, the application that is simulating the entity is responsible for updating its position and health status. VR-Forces simulates the attached components. You can specify that VR-Forces simulate the components on one back-end or across all back-ends.
Simulation of components on remote entities has the following limitations:
Only individual platforms and lifeforms can attach components. Units and envi- ronmental process objects are not supported.
./data/simulationModelSets/<model_set>/extra/componentAttachmentTable.mtl.
The component attachment table associates entities with attachment key-names. The following is a sample component attachment table:
(remote-configurations (attachment-entry
;; CIS MIG 29
(attach-by object-type (obj-type 1 (1 2 222 1 2 1 -1))) (key-name "mig29-config")
)
(attachment-entry
;; US F-18
(attach-by object-type (obj-type 1 (1 2 225 1 9 -1 -1))) (key-name "f18-config")
)
)
Attaching Components to Remote Entities — Attaching VR-Forces Components to Remote
Entities
The entries in this table associate the key-names mig29-config and f18-config with appropriate entity type enumerations. You can also associate a key-name with marking text, as follows:
(attachment-entry
(attach-by marking-text “HMMWV 1) (key-name "hmmwv-attachments")
)
The key-names in the component attachment table have corresponding entries in
vrfSim.opd in the remote-configurations block, as follows:
(remote-configurations (remote-configuration
(key-name "f18-config")
(configuration-path "$(remote-config-dir)/f18.mtl")
)
(remote-configuration
(key-name "mig29-config")
(configuration-path "$(remote-config-dir)/mig29.mtl")
)
The key-names are associated with specific configuration files, which by default are located in ./data/simulationModelSets/<model_set>/vrfSim/remoteConfigurations. The configuration files contain the components that are to be attached to the remote entity. For examples, please see the files in the remoteConfigurations directory.
The chapters in this section describe the display engine, windows, and channels, explain features of the graphical user interface (GUI), and how to configure menus and toolbars.
Section XII - Configuring the Graphical User Interface VR-Forces Users Guide
XII-1
Configuring the Graphical User Interface
Section XII - Configuring the Graphical User Interface
XII-2 VT MAK
77. Display Engine and Window Management
This chapter explains how to add and configure windows and channels and how to save display engine configurations.
Managing Display Engine Configurations 77-2
Adding a Channel to a Window 77-4
Saving a Display Engine Configuration 77-5
Loading a Display Engine Configuration 77-5
Changing a Window’s Attributes 77-6
Changing a Channel’s Attributes 77-7
Setting the Clipping Planes 77-9
Specifying the Projection Resize Policy Attribute 77-11
Changing a Channel’s Frustum (Field of View) 77-14
Configuring Water Visibility 77-16
Configuring Multichannel Displays 77-17
Changing the Camera’s Position and Orientation Offset 77-19
Configuring Anaglyphic Stereo 77-21
Configuring Polarized Stereo 77-22
Display Engine and Window Management — The Display Engine
VR-Forces supports the following types of windows:
Full screen. A full screen window uses the entire area of a monitor. It does not have any menus, panels, or other GUI controls.
Resizable. A resizable window can be moved, resized, maximized, and minimized. It does not have any GUI controls. An inset view is an example of a resizable window. (For information about inset views, please see “Inset Views,” on
Embedded. An embedded window is part of an application. The main display window in the VR-Forces front-end is an embedded window. The application provides a variety of controls that affect the view in the window. You could, if you wanted to, change VR-Forces’s window to a different type, in which case it would no longer be embedded in the main application window.
A window can have zero or more channels. Each channel defines a viewable area on the screen. You must have at least one channel to see a rendered image in the window. Each channel can have its own observer.
You can add windows to the display engine and you can add channels to the windows. The windows and channels make up a display engine configuration. You can save a display engine configuration and load a saved configuration.
You can add as many windows as you want. New windows are named for the window type, for example Stealth Inset 1, Stealth Inset 2, Plan View Inset 1, and so on. Each window is created with one channel. You can add new windows from the File menu or in the Display Engine Configuration Editor.
To add a window from the File menu, choose File New Stealth Window (or New Plan View Window). A new window opens (Figure 77-1).
To add a window from the Display Engine Configuration Editor:
Choose View Display Engine Configuration Editor Panel. The Display Engine Configuration Editor Panel is added to the VR-Forces window (Figure 77-2).
Figure 77-2. Display Engine Configuration Editor Panel
Display Engine and Window Management — Managing Display Engine Configurations
Select the display engine at the top of the Display tree.
Click the Add a Window button 
), or right-click the display engine name and choose Add a Window on the context sensitive menu. A new window opens and is listed in the Display Engine Configuration Editor Panel (Figure 77-3).
Adding a channel to a window lets you configure multiple views within that window.
In the Display Engine Configuration Editor Panel, select the window to which you want to add a channel.
Click the Add a Channel button 
), or right-click the window name and choose
Add a Channel from the menu.
To see a difference between the channels, change the attributes of the new channel (Figure 77-10). For details about editing channel attributes, please see “Changing a Channel’s Attributes,” on page 77-7.
In the Display Engine Configuration Editor Panel, select the window that you want to remove.
Click the Remove Window button 
), or right-click the window name and choose Remove Window from the menu.
To remove a channel:
In the Display Engine Configuration Editor Panel, select the channel that you want to remove.
Click the Remove Channel button 
), or right-click the window name and choose Remove Channel from the menu.
You can save a display engine configuration so that you can easily replicate the configu- ration at a later time.
To save a display engine configuration:
Click the Save Display Engine Configuration button 
), or right-click the name of the display engine and choose Save Display Engine Configuration on the menu. The Save Display Engine Configuration dialog box opens.
Type a name for the display engine configuration.
Click Save.
To load a display engine configuration:
In the Display Engine Configuration Editor Panel, select the display engine at the top of the window.
Click the Load Display Engine Configuration button ( ), or right-click the name of the display engine and choose Load Display Engine Configuration on the menu. The Load Display Engine Configuration dialog box opens.
Select the display engine configuration you want to load.
Click Open.
Display Engine and Window Management — Changing a Window’s Attributes
You can change the following attributes of a window:
Window Type (for details about window types, please see “Window Types,” on page 77-2).
Position (X, Y coordinates of upper left corner, in screen pixels).
Width and height, in pixels.
Fixed size.
To change a window’s attributes:
Click the value of the attribute that you want to change.
To change a numeric value, type or select a value.
To change the Window Type or Fixed Size, select a value from the list. To change the name, type a new name.
Click Commit Changes. The window is updated.
You can also change a window’s position by dragging it to a new location. You can change its size by resizing the window directly. The new values are shown in the attributes list the next time you select the window in the Display Engine Configuration Editor Panel.
You can change the following attributes of a channel:
Projection Units – field of view, in angles, or database, in meters.
Z Near and Z Far (clipping planes).
Near Far Clip Policy.
Reduce Z Fighting Ratio.
Dynamic Near Clip Attached Policy.
Attached Near Clip Altitude.
Fixed Near Clip When Attached.
Dynamic Water Visibility Enabled.
Camera Orientation Offset (Psi (heading), Theta (pitch), Phi (roll)).
Keywords – keywords to associate with the channel, for example, “showCockpits”.
To change a channel’s attributes:
Click the value of the attribute that you want to change.
To change a numeric value, type or select a new value.
To change the Observer Name, Sensor, Project Units, Projections Resize Policy, or Parent Channel, select a value from the list.
To change the Channel Name, type a new name. (For details about some of these attributes, please see the sections that follow this one.)
Click Commit Changes. The window is updated.
Figure 77-5 illustrates the effect of changing the near clipping plane (the Z Near attri- bute). Figure 77-6 illustrates the effect of changing the far clipping plane (the Z Far attributes).
Z Near = 1 Z Near = 500
Z Far = 10000000 Z Far = 10000
The ratio between the far clipping plane and the near clipping plane determines the precision with which the renderer can determine differences in depth. If this ratio becomes too small, then terrain and objects that are distant may not sort correctly, resulting in what is referred to as Z-fighting. VR-Forces provides different policies for managing the way near and far clipping planes are determined.
Fixed. Clipping planes are set explicitly using the Z Near and Z Far attributes.
Ignore Attached. Do not take entity attachment into account when setting the near clipping plane.
Fixed Near Clip. Set the near clipping plane to the value of the Fixed Near Clip When Attached attribute if the observer altitude is >= the value of the Attached Near Clip Altitude attribute.
If the settings described in this section do not reduce Z-fighting, you can try using reverse Z buffereing. To enable reverse Z buffering, start VR-Forces with the --userReverseZBuffer command-line option. However, the Oculus Rift HMD, simulation object labels, shadows, HUDs, and lightpoints do not work with reverse Z buffering.
The Projection Resize Policy determines how a channel behaves when you resize it. The options are:
Fixed. Keep the aspect ratio the same regardless of how the window is resized.
Horizontal. Maintain the horizontal aspect ratio when the window is resized.
Vertical. Maintain the vertical aspect ratio when the window is resized. Figure 77-7 illustrates the effect of different resize policies, as follows:
In the window with the fixed resize policy, all of the visual data in the initial view is still in the resized view, although the vertical dimensions are distorted.
In the window with the horizontal resize policy, the field of view is widened to maintain the correct aspect ratio of the visual data.
In the window with the vertical resize policy, the field of view is shortened.
You can change the projection resize policy for individual channels by editing the Projection Resize Policy attribute. You can also change the projection resize policy for all channels.
Initial view
Resized with Fixed resize policy
Resized with Horizontal resize policy
Resized with Vertical resize policy
Figure 77-7. Effect of different projection resize policies
To change the projection resize policy for all channels:
Choose Settings Display. The Display Settings dialog box opens.
Select the Render Settings page (Figure 77-8).
Select an option on the Channel Projection Resize Policy list.
The field of view setting affects perspective in a manner similar to a camera lens.
A wide field of view creates an effect like that of a wide-angle lens. Objects appear smaller and farther away from the observer, since the observer coverage spans a wider area. Depth distances between objects become exaggerated.
A narrow field of view creates an effect like that of a telephoto lens. Objects appear larger and closer to the observer, and the overall scene depth appears flattened. The distances between objects appears compressed.
Figure 77-9 illustrates different field of view settings taken from the same observer loca- tion. The view on the left has frustum values -22.5, 22.5, -22.5, 22.5. The view on the right has the frustum values -10, 10, -10, 10.
To change a channel’s field of view, edit the frustum values in its attributes list.
When you change the viewport of a channel, you change the portion of the window in which the channel is displayed. This does not change the extents of the scene. A narrow viewport compresses the scene width. A short viewport compresses the height. Figure 77-10 shows a window that has three channels, each with a different viewport. (The arrows show which portion of the window corresponds to each channel.) Notice that each channel has the same field of view.
Figure 77-10. Window with three channels and three viewports
Viewports are specified as a percentage of the window from left to right and top to bottom. Figure 77-11 shows the percentage allocation for the viewports in (Figure 77-10).
0 50% 100%
Left: | 0 | Left: | 50 |
Right: | 50 | Right: | 100 |
Top: | 100 | Top: | 100 |
Bottom: | 50 | Bottom: | 50 |
Left: | 0 | Left: | 50 |
Right: | 50 | Right: | 100 |
Top: | 50 | Top: | 50 |
Bottom: | 0 | Bottom: | 0 |
Left: | 0 | Left: | 50 |
Right: | 50 | Right: | 100 |
Top: | 100 | Top: | 100 |
Bottom: | 50 | Bottom: | 50 |
Left: | 0 | Left: | 50 |
Right: | 50 | Right: | 100 |
Top: | 50 | Top: | 50 |
Bottom: | 0 | Bottom: | 0 |
50%
0
Figure 77-11. Viewport configuration
When you change viewports, the window might not completely refresh. To see the changes, resize the window.
The water visibility attributes (along with the surface transparency setting on the Envi- ronment Conditions dialog box, Weather page) are designed to reduce Z fighting. Z- fighting occurs when the altitude of the ocean surface and the depth of the ocean floor are very close to each other, usually around coastlines that have bathymetry data. The likelihood of Z-fighting decreases as the difference between the ocean surface and ocean floor increases, but it increases as the observer’s altitude increases (because the ocean surface and ocean floor are proportionally closer to each other). Therefore there is a dynamic relationship as these factors change.
Adding transparency to the water reduces Z-fighting. The Dynamic Water Visibility Enabled attribute increases transparency automatically as the observer’s altitude increases. Dynamic Water Visibility Maximum specifies the maximum depth to which transparency is added (Figure 77-12).
Apply transparency in this area
Ocean surface
Ocean floor
Dynamic Water Visibility Max
Figure 77-12. Dynamic water visibility
Dynamic water visibility is enabled by default. When Dynamic Water Visibility Enabled is True, VR-Forces increases the water visibility depth from the value Surface Transparency setting (at 0 meters altitude), to the maximum value specified at the current Ocean LOD Elevation. The default depth is 75 meters. This value provides reasonable performance given the default Ocean LOD Elevation (5000 meters), the altitude above which VR-Forces stops displaying dynamic ocean. If you change the Ocean LOD Elevation so that dynamic ocean is displayed when the observer is higher than 5000 meters, Z-fighting may increase and you may need to increase the Dynamic Water Visibility Maximum value. (For details about setting the Ocean LOD Elevation, please see “Setting the Ocean LOD Elevation,” on page 55-16.)
There is no performance cost to enabling this attribute when you are not using dynamic ocean. If there are no underwater terrain polygons, these attributes have no effect.
People running simulations often want to set up a multichannel configuration using multiple monitors (on one or more computers) to display exercises. Typical configura- tions are a horizontal alignment, which widens the view, and the angled alignment, which surrounds the observer to simulate an out-the-window view (Figure 77-13).
You could set up these display configurations by having one computer with several monitors attached, or you could have multiple computers, each running a VR-Forces front-end. You might also want to have a 2D view on one monitor and a 3D view on another.
Observer Observer
Figure 77-13. Multi-channel displays (top-down view)
By default, all windows and channels show the same view of the terrain (Figure 77-15, default window views). Therefore, if you want a setup in which each channel shows a different view of the terrain, you must configure the channels to calculate an offset from the master view.
The distribution of the view across multiple channels is controlled by the frustum. Figure 77-14 illustrates the default frustum for Channel 1. It has a 60o field of view, from -30o to +30o.
Top | |||
-30o | 30o 30o | ||
Left | -30o | Right | |
Bottom | |||
Figure 77-14. Default frustum for Channel 1
If you wanted to split the view into, for example, three horizontal channels, you would edit the left and right frustum values for each channel, as shown in Figure 77-15. The field of view is the same: -30o to +30o. However, now each channel shows a 20o
segment of the total field of view.
-30o -10o 10o 30o
Left Right
Default window views
Views after changing frustum values
Figure 77-15. Frustum values for three channels
Once you configure the windows and channels you need to create the views you want, save the display engine configuration on each computer that you have configured. The next time you run the scenario, load the appropriate display engine configurations on each computer.
For a multi-monitor configuration to work correctly, use fixed size windows whose size matches the aspect ratio specified by the horizontal and vertical fileds of view and set the projection resize policy to fixed. (For information about the projection resize policy, please see “Specifying the Projection Resize Policy Attribute,” on page 77-11.)
Changing the frustum affects how much of the database is in the view. Changing the camera’s position and orientation affects the point from which you look at the view. For example, imagine you are simulating the view from a vehicle, as in vehicle 1 in Figure 77-16. (The camera location is represented by the binoculars.)
1 2 3
Figure 77-16. Position and orientation offsets
If you wanted the gunner to look out the rear of the vehicle, you would change its orientation, with the Psi (heading), Theta (pitch), and Phi (roll) Camera Orientation Offsets (vehicle 3).
Active Stereo: In an active stereo setup, frames are alternated on the display for the left eye and the right eye, and a pair of shutter glasses blocks light to either the left or right eye in synchronization with the display. This method requires hardware support to synchronize the glasses to the display, along with a graphics card capable of quad buffering, and a display that can refresh at twice the desired frame rate. Active stereo should be possible with VR-Forces, but has not been tested.
Anaglyphic Stereo: Anaglyphic stereo is the cheapest and simplest method to use. A typical setup is a display showing a red channel and a cyan channel simultaneously, along with a pair of glasses with one red lens and one cyan lens for the viewer. This will work with no special hardware aside from the inexpensive glasses. It is also the simplest method to set up in VR-Forces, requiring only that some OpenScene- Graph environment variables be set.
Polarized Stereo: A polarized display shows the frames for both eyes simultaneously, but with their light polarized in different directions. The viewer wears glasses that have lenses polarized to match the two different frames, allowing each eye to see only the frame intended for it. Polarized stereoscopy requires some specialized equipment to display the images with the correct polarization. One simple method for producing this kind of display is to use two projectors with polarizing filters, projecting onto a rear projection screen. Monitors are available that can polarize the two frames. It is easy to configure a polarized display with VR-Forces.
Table 77-1: Environment variables for anaglyphic stereo
Environment Variable Description Default
Environment Variable Description Default
OSG_STEREO Turn stereo on. ON OSG_STEREO_MODE Use anaglyphic stereo when in stereo. ANAGLYPHIC
OSG_SCREEN_DISTANCE Specifies the distance, in meters, that
the viewer is from the screen.
OSG_SCREEN_HEIGHT Specifies the height of the image, in
meters, on the screen.
OSG_SCREEN_WIDTH Specifies the width of the image, in
meters, on the screen.
OSG_EYE_SEPARATION Specifies the eye separation (interoc-
cular distance).
0.50
0.26
0.325
0.06
Varying the eye spacing and focal length can produce different effects, and the best values may depend on what the viewer is looking at. Figure 77-17 shows an example configuration.
Left channel Right channel
Figure 77-17. Polarized stereo channel configurations
To compute the correct channel configuration values:
Pick a focal length, L. Objects at this distance will appear to be in the plane of the display. Objects that are further away will appear behind the display, and objects closer will appear in front of it.
Pick an eye spacing, E, to represent the distance between the viewer’s eyes. Human eyes are typically about 0.063m apart1.
Set the X Camera Position values to –E/2 meters for the left channel and E/2
meters for the right channel.
Set the Psi Camera Orientation values to –arctan(E/2)/L degrees for the left channel and arctan(E/2)/L degrees for the right channel.
1. “"Variation and extrema of human interpupillary distance", N. A. Dodgson, Proc SPIE 5291. Select publications link and scroll to 2004 at http://www.cl.cam.ac.uk/~nad10/pubs/EI5291A-05.pdf.
78. GUI Controls, Layouts, and Behaviors
This chapter provides details about using the various panels and toolbars in the front- end.
Dockable Panels and Toolbars 78-2
Docking and Undocking a Panel 78-2
Docking and Undocking a Toolbar 78-3
Displaying and Hiding Panels and Toolbars 78-3
Choosing the Window Layout 78-5
Setting a Window Layout as the Default Layout 78-5
Reverting a Window Layout 78-6
Restoring a Factory Layout 78-7
Viewing the Window in Full Screen Mode 78-9
Using Context-Sensitive Menus 78-9
Adding Text to the Title Bar 78-10
Specifying Display Units 78-11
GUI Controls, Layouts, and Behaviors — Dockable Panels and Toolbars
VR-Forces has floating, dockable panels for many of its important functions (Figure 78-1). It also has toolbars that let you quickly access the commands available on the menus.
Figure 78-1. VR-Forces window and undocked panels
To undock a panel:
Place the cursor over the panel’s title.
Press and hold the left mouse button.
Drag the panel away from the window.
To dock a floating panel, double-click its title bar.
To undock a toolbar:
Place the cursor over the handle.
Figure 78-2. Toolbar handle
Press and hold the left mouse button.
Drag the toolbar away from the window.
To dock a toolbar, drag it back to the toolbar strip. The other toolbars will move to create a space to drop in the toolbar (Figure 78-3).
Figure 78-3. Docking a toolbar
You can hide any of the panels or toolbars.
To hide or view a panel or toolbar, select it on the View menu.
You can save window layouts to named layouts and can easily switch between them while VR-Forces is running. A layout stores the window size and the visibility and loca- tion of all toolbars and panels. You can specify that a layout be the default layout used at startup.
Layouts get saved to ./appData/settings/vrfGui. Each layout is saved to a separate file using the naming convention layout_layout_name.uisx. For backup, you can save layouts to ./factory/settings/vrfGui.
VR-Forces includes two layouts to get you started. The Scenario Creation layout has a set of toolbars and panels that users typically need when creating a scenario. Scenario Viewer removes the toolbars and panels to maximize the amount of the window that displays the scenario.
When you shut down VR-Forces, it saves the window layout. If you do not specify a default window layout, when VR-Forces starts up, it uses the saved window layout.
To create a window Layout:
Arrange the toolbars, panels, and window size in the layout you want.
Choose View Window Layout Manager. The Window Layout Manager dialog box opens (Figure 78-4).
Click New. The Layout Name dialog box opens.
Type a name in the Layout Name box.
Click OK.
Select one of the window size options:
Maximize. Maximizes the window when this window layout is selected, regard- less of the window size when the layout is created.
Restore Window. Save the current window size as part of the window layout.
This is the default option.
Full Screen Mode. Put the window into full screen mode when this layout is selected, regardless of the window size when the layout is created.
Click OK. The layout is added to the list of layouts.
You can easily choose a window layout at any time. You can change layouts from the View menu or from the Layout Manager.
You can map keys to layouts to select them from the keyboard. Each layout can be mapped to a key (Figure 78-5). For details about mapping keys, please see Chapter 80, Creating and Editing Key Mappings.
Figure 78-5. Layout action in Key Mapping Editor
To choose a window layout, choose View Window Layouts layout, where
layout is one of the listed named layouts.
To change the window layout in the Window Layout Manager, in the list of layouts, double-click the layout you want to use or select the layout you want and click Switch To.
When VR-Forces starts, if there is a default layout, it uses that layout. Otherwise, it uses the window layout it saved the last time you shut down VR-Forces.
To set a window layout to be the default layout:
Choose View Window Layout Manager. The Window Layout Manager dialog box opens (Figure 78-4).
In the list of layouts, select the layout you want to be the default.
Click Make Default. A star is displayed next to the name of the layout to indicate it is the default layout.
To clear the default layout:
Choose View Window Layout Manager. The Window Layout Manager dialog box opens (Figure 78-4).
To specify a different default layout, select the desired layout and click Make Default.
To just clear the current default layout, in the list of layouts, select the default layout and click Clear Default.
If you use a named window layout and then rearrange the window, you can revert to the saved layout.
To revert a window layout, choose View Revert Window Layout. (You can also revert a layout on the Window Layout Manager dialog box.)
If you load a window layout and then make changes to the layout, such as resizing the window or closing a panel, VR-Forces does not keep track of the changes. If you switch to a different layout or shut down, the changes are lost. If you want to save changes to a layout, you must explicitly update it.
To update a window Layout:
Choose View Window Layout Manager. The Window Layout Manager opens (Figure 78-4).
Select the layout you are using.
Click Update.
You can change the name of a window layout.
To rename a window layout:
Choose View Window Layout Manager. The Window Layout Manager dialog box opens (Figure 78-4).
Select the layout you want to rename.
Click Rename. The Layout Name dialog box opens.
Type a new name for the layout.
Click OK.
You can delete window layouts that you have created.
To delete a window layout:
Choose View Window Layout Manager. The Window Layout Manager dialog box opens (Figure 78-4).
Select the layout you want to delete.
Click Delete.
VR-Forces includes two layouts. They are in ./appData/settings/vrfGui, which makes them available to the Layout Manager. They are also in ./factory/settings/vrfGui so that they can be restored. All layouts created after you install VR-Forces are saved to
./appData/settings/vrfGui. If you want to back up your layouts, you can copy them to any backup location you want. If you want to be able to restore a layout in the Layout Manager, copy it to ./factory/settings/vrfGui.
To restore a layout from the factory, it must be present in ./appData/settings/vrfGui so that you can select it in the Layout Manager. If you delete a layout and then want to recover it, if you have saved a copy of it to ./factory/settings/vrfGui or anyplace else, you can copy it to ./appData/settings/vrfGui.
To restore a window layout to the factory layout:
Choose View Window Layout Manager. The Window Layout Manager dialog box opens (Figure 78-4).
Select the layout you want to restore.
Click Restore From Factory.
GUI Controls, Layouts, and Behaviors — Using Tear-Off Menus
You can “tear-off” the Create menu and leave it displayed on the desktop.
To tear off the Create menu:
Click the Create menu.
Move the cursor over the grab bar (dashed line) at the top of the menu to highlight it (Figure 78-6).
Right-click. The menu is displayed as a window that you can leave open and repo- sition.
Figure 78-6. Tearing off a menu
GUI Controls, Layouts, and Behaviors — Common VR-Forces Buttons
You can configure VR-Forces to start in full screen mode with the --fullScreen command-line option. If you are viewing a simulation that takes place primarily over the ocean, you may get better performance using the --pseudoFullScreen command-line option.
To view VR-Forces in full screen mode, choose View Show Full Screen, or press
Ctrl+Enter.
To exit full screen mode, press Ctrl+Enter.
VR-Forces has context sensitive menus (also called popup menus or right-click menus) that you can display by clicking the right mouse button.
If you right-click a simulation object, tactical graphic, or other scene object, the menu displays the actions that you can take.
If you right-click the menu bar, you can select the commands available on the View menu.
VR-Forces dialog boxes have a common set of buttons, as follows:
Add an item (definition, model, and so on).
Remove the selected item.
Copy the selected item and add the copied version to the list.
Select a filter of some type.
Rename the selected item.
Add from a list.
Move up in the list.
Move down in the list.
Select the previous item.
Select the next item.
Add an attribute.
Remove local attribute definition and use the parent’s definition.
Search.
GUI Controls, Layouts, and Behaviors — Adding Text to the Title Bar
To add text to the title bar:
Choose Settings Application. The Application Settings dialog box opens.
Select the Session Options page (Figure 78-7).
Select the Use Additional Window Title check box.
Type the text you want to display in the text box.
You can specify the units used to display coordinate system, distance, altitude, and other measurements. Display units are configured by measurement type. This means that you can use different measurement units for different types of data. You can also specify the number of decimal places for measurement values. When you change a measurement display unit, the changes take effect immediately. They are saved and applied the next time you run VR-Forces.
The following coordinate system and unit display information is independent of (and therefore not affected by) the settings described in this section:
The coordinate system information for the observer location in the Observer Information Panel.
Grid line coordinates, units, and precision.
The types of data and the display objects that they affect are as follows:
Coordinate system
Distance
Altitude
Velocity (speed)
Acceleration
Rotational velocity
Orientation (heading).
Table 78-1 describes the coordinate systems that you can specify.
Table 78-1: Coordinate systems supported
Coordinate system Description
Coordinate system Description
Latitude/Longitude (degrees:minutes:secon ds)
Latitude/Longitude (decimal radians)
Location is displayed as two position fields and one alti- tude field. Displays coordinates in the latitude and longi- tude using the geodetic WGS84 coordinate system. Each angle is displayed in degrees:minutes:seconds with seconds displaying base 10 fractional seconds.
Location is displayed as two position fields and one alti- tude field. Position coordinates in the latitude and longi- tude using the geodetic WGS84 coordinate system. Each angle is displayed in decimal radians.
Geocentric Location is displayed as three position fields. Position coor-
dinates are displayed in the geocentric coordinate system. The position fields are always in meters.
Table 78-1: Coordinate systems supported
Coordinate system Description
Coordinate system Description
UTM Location is displayed as two position fields and one alti- tude field. Position coordinates are displayed in the Universal Transverse Mercator system. The first position field displays the zone and the x location in meters. The second position field displays the y position in meters.
MGRS Location is displayed as two position fields and one alti- tude field. Position coordinates are displayed in the Military Grid Reference System. The first position field displays the zone. The second position field displays the grid location. The precision controls the number of digits used in the grid display.
Database Location is displayed as three position fields. Location is displayed using VR-Forces’s current internal cartesian database system. The position fields are displayed using the current distance units.
To specify measurement units:
Choose Settings Display. The Display Settings dialog box opens.
Select the Display Units Settings page (Figure 78-8).
Select the measurement unit you want for each option from its list.
Type a precision for each measurement unit in the corresponding box in the Decimal Places column.
79. Configuring Toolbars, Dialog Boxes, and Menus
This chapter explains how to specify which menus, menu options, toolbars, and dialog box pages get displayed in the graphical user interface (GUI).
Configuring Menus and Menu Commands 79-2
Configuring Dialog Box Pages 79-3
Configuring Context-Sensitive Menus 79-5
Specifying an Icon for a Toolbar Item 79-7
Locking Main GUI Elements 79-7
Configuring Toolbars, Dialog Boxes, and Menus — Introduction
VR-Forces displays menus, menu commands, toolbars, dialog box pages, and popup menus based on the information in an XML configuration file. The default file is
./appData/settings/vrfGui/default_guiConfiguration.gui. You can edit this file or create
alternative GUI configuration files. VR-Forces includes an example of a simple GUI configuration file, ./appData/settings/vrfGui/default_guiSimpleScenarioPlayer.gui, that shows how you might create a highly modified GUI. You can specify an alternative GUI configuration file with the --gui command-line option when you start VR- Forces.
The elements in the configuration file are fairly self-explanatory. This chapter provides a brief description of the file.
For those GUI elements that can be rearranged, such as toolbars, the .gui file provides the initial organization of GUI elements. If a user rearranges toolbars, the new layout is saved in the settings file and overrides the .gui file.
Menus are configured in the <mainmenuconfiguration> element. Each menu is configured in a <mainmenu> element. Menu commands are configured in
<menuitem> elements. The following example configures a menu bar with one menu that has two items, which are separated by a separator line.
<mainmenuconfiguration name="main_menu_configuration">
<mainmenu menuname="DtFileMenu">
<menuitem itemname="DtNewScenarioMenuItem"/>
<separator separatorname="1"/>
<menuitem itemname="DtExitItem"/>
</mainmenu>
The values for the menuname and itemname attributes must be valid IDs registered in VR-Forces code. default_guiConfiguration.gui has all of the valid IDs for menus and menu commands.
To remove a menu or menu command from the GUI, delete the applicable element from default_guiConfiguration.gui or create an alternative file that does not have the elements. To add menus or menu items, you must know the ID.
Configuring Toolbars, Dialog Boxes, and Menus — Configuring Dialog Box Pages
Dialog boxes such as Display Settings and Terrain Settings have multiple pages for configuring different features. The GUI configuration file lets you disable or enable the pages on dialog boxes. The dialog boxes are configured as <pagecollection> elements inside the <pagecollections> element. The following example config- ures the Application Settings dialog box:
<pagecollections name="page_collections">
<pagecollection pagecollectionname="DtApplicationSettings" title="Application Settings" location="8" visible="True" index="-1" show="DtKeyMappingEditorPage" closable="True" floatable="True" movable="True">
<pageitem pageitemname="DtKeyMappingEditorPage"/>
<pageitem pageitemname="DtMouseMappingEditorPage"/>
<pageitem pageitemname="DtInterfaceLayoutEditorPage"/>
<pageitem pageitemname="DtPerformanceOptionsPage"/>
<pageitem pageitemname="DtSpotReportOptionsPage"/>
<pageitem pageitemname="DtSessionOptionsPage"/>
<pageitem pageitemname="DtScriptedTaskOptionsPage"/>
<pageitem pageitemname="DtEntityBehaviorOptionsPage"/>
</pagecollection>
<informationpagecollection> elements. The following example is part of the Information dialog box. The page is broken up into sections. The first section displays summary data. The second section has the individual pages and specifies the informa- tion on each page.
<informationpagecollections name="information_page_collections">
<pagecollection pagecollectionname="DtEntityInformation" title="Entity Information" location="9" visible="True" index="-1" show="DtTaskStatePage" closable="True" floatable="True" movable="True">
<section sectionname="DtEntityCompactData" maximumHeightIsMinimumHeight="true">
<informationitem informationitemname="DtEntityIcon" row="0" col="0" rowspan="2" width="50"/>
<informationitem informationitemname="DtStateMarkingText" row="0" col="1"/>
<pageitem pageitemname="DtInformationIconBar" row="1" col="1" width="20">
<informationitem informationitemname="DtEmbarkedOnItem"/>
</pageitem>
<informationitem informationitemname="DtCreatePaletteName" row="0" col="2"/>
<pageitem pageitemname="DtSensorInformationPage" row="1" col="2"/>
<informationitem informationitemname="DtEntitySpeed" row="0" col="3" width="128"/>
<informationitem informationitemname="DtEntityAltitude" row="1" col="3" width="128"/>
<pageitem pageitemname="DtTaskStatePage" row="0" col="4" width="128"/>
Configuring Toolbars, Dialog Boxes, and Menus — Configuring Dialog Box Pages
<informationitem informationitemname="DtObjectConsoleInformationStatusItem" row="1" col="4"/>
</section>
<section sectionname="DtEntityExpandedData" collapsible="True" tabbed="small" collapsed="True" title="Detailed Information">
<pageitem pageitemname="DtTaskStatePage"/>
<pageitem pageitemname="DtEntityInformationPage">
<informationitem informationitemname="DtEntityLocation"/>
<informationitem informationitemname="DtEntitySpeed"/>
<informationitem informationitemname="DtEntityAltitude"/>
<informationitem informationitemname="DtEntityVelocity"/>
<informationitem informationitemname="DtEntityAcceleration"/>
...
<informationitem informationitemname="DtEntityStateFrozen"/>
<informationitem informationitemname="DtEntityStateDRAlgorithm"/>
</pageitem>
<pageitem pageitemname="DtEntityAttributesPage"/>
<pageitem pageitemname="DtResourceInformationPage"/>
...
</section>
<section sectionname="DtObjectConsoleSection" title="Object Console" collapsible="true" collapsed="true" maximumHeightIsMinimumHeight="true">
<pageitem pageitemname="DtObjectConsoleInformationWidget"/>
</section>
</pagecollection>
...
</informationpagecollections>
Notice that by default, the DtTaskStatePage does not have any <informationitem> elements. The information on that page is generated dynamically. There are no static fields.
Configuring Toolbars, Dialog Boxes, and Menus — Configuring Context-Sensitive Menus
<rightclickmenu> elements. There are multiple versions of these elements to account for the different contexts in which a menu might be displayed, for example, one unit, multiple single entities, a mix of entities and control objects. The following example is part of the context-sensitive menu for multiple entities:
<rightclickmenus name="right_click_menus">
<rightclickmenu rightclickmenuname="Multiple_Entity">
<popupmenu menuname="DtVrfRightClickContextMenu">
<menu menuname="DtRightClickTaskMenu"/>
<menu menuname="DtRightClickSetMenu"/>
<separator separatorname="2"/>
<menuitem itemname="DtVrfEntityAbandonPlanAction"/>
<menuitem itemname="DtVrfEntityRestartPlanAction"/>
<menuitem itemname="DtVrfEntityPlanAction"/>
<menuitem itemname="DtVrfManageReactiveTasksActionId"/>
<menuitem itemname="DtVrfEntitySkipTaskAction"/>
<separator separatorname="110"/>
<menuitem itemname="DtVrfAggregateAsAction"/>
<menuitem itemname="DtExpandAggregateMenuItem"/>
<menuitem itemname="DtExpandAllAggregateMenuItem"/>
<menuitem itemname="DtCollapseAggregateMenuItem"/>
<menuitem itemname="DtCollapseAllAggregateMenuItem"/>
<menuitem itemname="DtObjectSettingsAction"/>
...
<menuitem itemname="DtZoomToExtentsAction"/>
<separator separatorname="DtInformationItemSeparator"/>
<menuitem itemname="DtVrfVrlinkObjectInformationItem"/>
</popupmenu>
</rightclickmenu>
<rightclickmenus name="right_click_menus">
Notice that the entries for the Task menu (DtRightClickTaskMenu) and the Set menu (DtRightClickSetMenu) do not have any <menuitem> elements. That is because these menus are themselves context-sensitive and get built dynamically.
Configuring Toolbars, Dialog Boxes, and Menus — Configuring Toolbars
You can configure use of the various toolbars provided with VR-Forces. For each displayed toolbar, you can configure which row it is in and which command icons are used. The following example shows that the Scenario toolbar is in the top row:
<toolbarconfiguration name="toolbar_configuration">
<toolbarrow toolbarname="Top_Row">
<toolbar toolbarname="DtScenarioToolbar" visible="True" floating="False">
<item itemname="DtNewScenarioMenuItem"/>
<separator separatorname="DtScenarioToolbar_1"/>
<item itemname="DtLoadScenarioMenuItem"/>
<item itemname="DtLoadBatchScenarioMenuItem"/>
<separator separatorname="DtScenarioToolbar_2"/>
<item itemname="DtSaveScenarioMenuItem"/>
<separator separatorname="DtScenarioToolbar_3"/>
<item itemname="DtCloseScenarioMenuItem"/>
</toolbar>
</toolbarrow>
</toolbarconfiguration>
Since toolbars are just buttons that reference existing menu options, you can create your own toolbars as easily as you add, delete, or edit the toolbars provided with VR-Forces. Simply add a toolbar element in one of the toolbarrow elements.
If you want to add tasks or sets to the Task or Set toolbars, or create a new toolbar, specify the itemname using the task or set ID as listed in ./include/vrfGuiCon- stants/vrfMenuIds.h. If you want to add a scripted task to a toolbar, the itemname is its script ID plus “ToolbarItem”. For example, if you add the Place IED scripted task to the Task toolbar, it would look like this:
<toolbar toolbarname="DtTaskToolbar" visible="True" floating="False">
<item itemname="DtVrfTaskMoveToActionToolbarItem"/>
<item itemname="DtVrfTaskMoveToLocationActionToolbarItem"/>
<item itemname="DtVrfTaskMoveAlongRouteActionToolbarItem"/>
<item itemname="DtVrfTaskMoveToAltitudeActionToolbarItem"/>
<item itemname="DtVrfTaskPatrolObjectsActionToolbarItem"/>
<item itemname="DtVrfTaskPatrolRouteActionToolbarItem"/>
<item itemname="DtVrfTaskEmbarkActionToolbarItem"/>
<item itemname="DtVrfTaskDisembarkActionToolbarItem"/>
<item itemname="Place_IEDToolbarItem"/>
</toolbar>
Configuring Toolbars, Dialog Boxes, and Menus — Locking Main GUI Elements
If you add an item to a toolbar, you can associate an icon with the toolbar button. To associate an icon with a scripted task, specify it in the Scripts dialog box. For details, please see “Specifying a Menu Icon,” on page 32-11. For tasks or sets, create an SVG file and put it in ./data/Icons. The file should use the menu ID of the task or set (from
./include/vrfGuiConstants/vrfMenuIds.h) with the DtVrf text and Action text stripped from it. For example, the icon for DtVrfTaskMoveToAltitudeAction is TaskMoveToAlti- tude.svg. The icon for DtVrfSetHeadingAction is SetHeading.svg.
VR-Forces plug-ins can modify menus, dialog boxes, and other GUI features. You can lock GUI settings for first level elements (elements under the root element). This feature is used in ./appData/settings/vrfGui/default_guiSimpleScenarioPlayer.gui. The syntax would be as follows:
<mainmenuconfiguration name="main_menu_configuration" locked="True">
...
</mainmenuconfiguration>
Given this configuration, none of the menus on the main menu could be modified.
Configuring Toolbars, Dialog Boxes, and Menus — Locking Main GUI Elements
80. Creating and Editing Key Mappings
This chapter explains how to edit key mappings and create new key mappings.
Using Combined Key Mappings 80-8
Filtering the Function List 80-9
Creating and Editing Key Mappings — Introduction
Creating and Editing Key Mappings — The Key Mapping Editor
The Key Mapping Editor (Figure 80-1) lists all of the functions that you can control from the keyboard and the keys to which they are mapped. Some functions are mapped to more than one key or key combination. A key can be mapped to more than one function (combined mappings). You can:
Edit a function’s key mappings.
Add new mappings.
Delete mappings.
Changes are saved automatically.
Figure 80-1. Key Mapping Editor
Many navigation functions require you to press and hold a key. For example, you press and hold W to move the observer forward. (By contrast some keyboard actions are toggles or unary functions, such as pressing period to attach to the next simulation object.) For these actions, VR-Forces needs to keep track of when the key is pressed down (start the action) and when it is released (stop the action). To a human user, a function like Move Observer Forward is experienced as one action. But the computer experiences it as two actions. Therefore, key mappings must take this into account. The Key Mapping Editor shows the key mappings for these functions as paired functions that are subordinate (children) to the primary function (the parent), as shown in the Move Observer Up entry in Figure 80-1.
The Key Mapping Editor lists all of the VR-Forces functions that you can control from the keyboard.
To edit a key map:
Choose Settings Application. The Application Settings dialog box opens.
Select the Key Mapping Editor page (Figure 80-1).
Select the function whose key mappings you want to edit.
Edit the key mappings as described in:
Optionally, export the key map to a file.
Click OK.
If a function is not mapped to a key, it is marked <unmapped>. You can add a mapping to unmapped functions and you can add additional key mappings to functions that are already mapped. If you add a key mapping to a binary function, the Key Mapping Editor automatically applies it to the child (UP and DN) functions. You can add key mappings to the child functions of binary mappings. When you add a key mapping to a child function, it is not applied to its paired function or the parent function.
In most cases, an unmapped function is unmapped because it is not meaningful in the observer frame for the key mapping. For example, the level observer movement functions are not meaningful in the observer frame key mappings.
To add a key mapping:
Optionally, filter the function list. For details, please see “Filtering the Function List,” on page 80-9.
Select the function to which you want to add a key mapping.
Click the Add button ( ) above the Key Map window (Figure 80-2). The Key Entry dialog box opens (Figure 80-3).
Function list Key mappings Key Map
Figure 80-2. Key Mapping Editor
On the keyboard, press the key or key combination (such as Ctrl+key or
Shift+key) that you want to map to this function.
Click OK. (If you choose a key combination that is already in use, VR-Forces noti- fies you and asks how to proceed. For details about duplicate key mappings, please see “Using Combined Key Mappings,” on page 80-8.) The mapping is added to the function and is listed in the Keys column of the function list and in the Key Map window.
If a key mapping is assigned to a binary function, the key is automatically assigned to the child functions. You cannot edit the key mappings for the child functions. You can only change the parent’s key mapping. However, if you add a key mapping to a child function, you can edit it.
To change a key mapping:
Select the function whose key mapping you want to change. Its key mappings get listed in the Key Map window (Figure 80-2).
In the Key Map window, select the key mapping that you want to change.
Click the Edit Key Mapping button 
). The Key Entry dialog box opens (Figure 80-4). It shows the current key mapping.
On the keyboard, press the key or key combination (such as Ctrl+key or
Shift+key) that you want to map to this function.
Click OK. The mapping is changed.
To delete a key mapping:
Select the function whose key mapping you want to delete. Its key mappings get listed in the Key Map window (Figure 80-2).
In the Key Map window, select the key mapping that you want to delete.
Click the Delete button ( ) above the Key Map window. The mapping is deleted. The function list is updated.
Creating and Editing Key Mappings — Using Combined Key Mappings
You can assign a key combination to more than one function. This allows you to combine the behaviors of two or more functions into one key combination. For example, the Z key detaches the observer from the attached simulation object. The Space Bar resets the observer view to the default view. Suppose that whenever you detach from a simulation object, you want the observer to return to the default view. You could map the Reset function to Z. Z is now mapped to two functions. When you press Z, VR-Forces detaches from the attached simulation object and moves the observer to the default view.
To manage combined key mappings:
Add the appropriate key mapping to a function.
Click OK. The Key Already Mapped dialog box opens (Figure 80-5). It lists the functions that already use this key mapping.
If the functions listed are the ones with which you want to share this key mapping, click Add. The key mapping is added to the function.
If you do not want to share this key mapping with other functions and want to use it for the function that you are editing, click Replace. The key mapping is applied to the function you are editing and removed from the functions listed in the dialog box.
If you do not want to remove the key mapping from existing functions and do not want to share it with the other functions, click Cancel. Presumably you wanted a unique key mapping for the function you are editing and did not realize you chose one that was already in use. Choose a different key mapping for this function.
Creating and Editing Key Mappings — Deleting a Key Map
You can filter the function list in the Key Mapping Editor. Functions are grouped thematically.
To filter the function list, click the Filter button ( ) and select an option on the list.
To create a key map:
Choose Settings Application.The Application Settings dialog box opens.
Select the Key Mapping Editor page (Figure 80-1).
Click the Add button ( ). The Create New Key Map dialog box opens.
Type a name for the new key map.
Click OK.
Add key mappings for the movement actions as described in “Adding a Key Mapping,” on page 80-5.
To delete a key map:
Choose Settings Application.The Application Settings dialog box opens.
Select the Key Mapping Editor page (Figure 80-1).
In the key mapping list, select the key mapping that you want to delete.
Click the Delete button ( ).
Confirm that you want to delete the selected key map.
Creating and Editing Key Mappings — Deleting a Key Map
XIII. Configuring Visual Models in the Visual Models Editor
When VR-Forces discovers a simulation object (entity or unit) on the network, it must decide how to represent it in the GUI. This is accomplished by mapping 3D models and 2D icons to object type enumerations. The chapters in this section explain how models and iconography are configured and mapped to object types.
The objects that VR-Forces can display that are not part of the terrain, such as simula- tion objects, tactical graphics, detonations, and cockpit displays, are generically called scene elements. Scene elements are defined in element definitions. When VR-Forces runs a scenario, it publishes information about the objects it is simulating. It may also receive object information over the network from other simulation participants. The objects are identified using object type enumerations. VR-Forces maps these object types to element definitions. (For more information about object type enumerations and mapping them to element definitions, please see “Introduction to Object Type Mapping,” on page 82-2.)
An element definition is a set of visual definitions that tell VR-Forces how to render (display) the object. Visual definitions specify the 3D model, 2D icon, or graphic, and the visual effects that the object supports, such as trailing effects, height-above-terrain lines, track histories, and so on. A scene element can have up to three different element definitions – one for each model set (3D, 3D Colorized, 2D Icon). VR-Forces chooses the correct element definition to use based on the model set being used by the observer. (For more information about model sets, please see “Model Sets,” on page 80-6.)
Element definitions are created and edited in the Visual Model Editors dialog box. In addition to letting you manage element definitions, this dialog box lets you create and manage model definitions and schemas. Model definitions specify values for some basic object parameters. Most importantly for most VR-Forces users, model definitions specify the 3D model to use for element definitions in the 3D Models model set. What this means is that if you want to add a new model to VR-Forces, you will specify the model file, such as an OpenFlight file, in a model definition and then specify that model definition in the element definition for the simulation object you want to add.
The chapters that discuss how to configure visual models do so in the context of using the Visual Models Editor dialog box. We strongly recommend that whenever possible you use the Simulation Object Editor to add and configure visual models. The only time that you should have to use the Visual Models Editor dialog box is if you need to add a new schema or edit model attributes that are not supported by the Simulation Object Editor. For details about how to use the Simulation Object Editor, please see Section XI, Creating and Editing Simulation Models and the chapters in that section.
Section XIII - Configuring Visual Models in the Visual Models Editor
XIII-2 VT MAK
Schemas define the most basic scene elements, such as an entity, SpeedTree tree, or line. Most VR-Forces users will never have to create or edit a schema. However, if you create a new model definition, you must make sure it uses the correct schema and that it includes all required parameters.
Figure 80-1 illustrates these relationships using an M1A2 entity. VR-Forces receives the object type 1:1:225:1:1:3:-1 over the network (callout 1). In the Simulation Object Type Mappings dialog box, this object type is mapped to the M1A2 Abrams entity defi- nition (2). (An entity definition is a specific type of element definition.) The M1A2 Abrams entity definition (in the Visual Model Editors dialog box) specifies all of the visual definitions for this entity (3). The Main Model visual definition has a modeldefini- tion parameter. The value for this parameter is TrackedM1A2DESERT. The TrackedM1A2DESERT model definition has a filename parameter that specifies M1A2.medf as the model to use for entities that use this model definition (4). The TrackedM1A2DESERT model definition has a filename parameter because it uses the Entity schema and the Entity schema requires a filename (5).
When you add simulation objects and other scene elements in the Simulation Object Editor, it creates model definitions and handles all of the mappings described in the previous paragraphs and the illustration. Although this manual explains all of the details of the Visual Model Editors dialog box and Simulation Object Type Mappings dialog box, using the Simulation Object Editor to add simulation objects is the preferred method.
DIS or HLA network
1 1:1:225:1:1:3:-1
2
3
4
5
Figure 80-1. Element definitions and simulation object type mapping
Section XIII - Configuring Visual Models in the Visual Models Editor
XIII-4 VT MAK
VR-Forces includes 3D models for vehicles, lifeforms, environmental objects, and effects. The models are in a compressed, encrypted format (extension .medf).
VR-Forces includes a utility, the MEDF Tool, that lets you encrypt files in MEDF format. You cannot use it to decrypt encrypted files. For more information, please see “Compressing Model Files,” on page 83-27.
You can provide your own models if they are in one of the following supported formats:
OpenFlight.
3ds.
OBJ.
COLLADA (.dae).
OSG (.osg, .osgb, and .ive).
NewTek LightWave (.lwo and .lws).
MAK GDB.
The model or icon that is used for an object is determined by its element definition. For convenience, element definitions are organized into model sets. For example, all of the element definitions that specify 3D models are in the 3D Models model set, and so on. As a result, when you choose the 3D Models model set for an observer mode, all of the entities use a 3D model. (The model set is an observer-specific setting.)
VR-Forces includes the following types of object models and icons:
3D Models. Realistic 3D models. This is the default model set for the Stealth observer mode.
3D Colorized Models. 3D colorized models are cartoon-like models that create an exaggerated notional view of the world. This is the default model set for XR observer mode.
2D Icons. 2D MIL-STD 2525B font-based icons. This is the default model set for the Plan View observer mode. You can also configure VR-Forces to use 2525a images or any arbitrary images for 2D icons.
i The model sets are fixed. You cannot add model sets.
For information about changing model sets, please see “Changing the Model Set,” on page 48-11.
Section XIII - Configuring Visual Models in the Visual Models Editor
XIII-6 VT MAK
81. Model and Element Definitions
In Section XIII, “Configuring Visual Models in the Visual Models Editor,” we describe the interplay of schemas, model definitions, simulation object definitions, and model mapping. This chapter explains how to create and edit model definitions and model schemas. “Adding a Model to VR-Forces,” on page F-2 walks you through the process of adding a model.
Managing Model and Element Definitions 81-3
Creating and Editing Schemas 81-4
Adding a Parameter to a Schema 81-7
Deleting a Parameter from a Schema 81-8
Editing a Schema Parameter 81-8
Creating and Editing Model Definitions 81-9
Work Flow Issues for Creating and Editing Model Definitions 81-10
Creating a Model Definition 81-12
Deleting a Model Definition 81-13
Copying a Model Definition 81-14
Filtering the List of Model Definitions 81-15
Editing a Model Definition 81-15
Saving Model Definitions 81-18
Importing Model Definitions 81-19
Exporting Model Definitions 81-20
Creating and Editing Element Definitions 81-21
How Entity, Unit, and Tactical Graphics Element Definitions are Organized 81-21
Model and Element Definitions
Work Flow Issues for Creating and Editing Element Definitions 81-23
Creating an Element Definition 81-24
Editing an Element Definition 81-25
Deleting an Element Definition 81-32
Saving Element Definitions 81-32
Importing Element Definitions 81-33
Exporting Element Definitions 81-35
Model and Element Definitions — Managing Model and Element Definitions
This chapter explains how to use the Visual Model Editors dialog box to create and edit schemas, model definitions, and element definitions. This process can be rather complex. If you are customizing the visual characteristics of the simulation objects provided with VR-Forces or adding new object types that are significantly different from those provided with VR-Forces, you may need to create new model definitions or edit the existing ones. However, if you just need to add new object types that are similar to existing ones, it is strongly recommended that you do so in the Simulation Object Editor.
When you create a simulation object in the Simulation Object Editor, it adds new model definitions and object type mappings automatically. You will not need to do anything in the Visual Models Editor to configure the new simulation object.
Model definitions and element definitions (visual definition files) are SMS-specific. The visual definition files for the SMSs provided with VR-Forces are stored in subdirec- tories of ./appData/definitions. If you create a new SMS, the visual definition files are stored as part of the SMS, in ./data/simulationModelSets/<sms>/gui/visuals. You can copy the visual definition files for the provided SMSs into the SMS hierarchy if you want to make it easier to copy an SMS to another VR-Forces installation.
When you open the Visual Models Editor, it loads the visual model definitions for the SMS used by the loaded scenario. If no scenario is loaded, it defaults to EntityLevel.sms. For details about how to edit visual models in the Simulation Object Editor, please see “Editing a Simulation Object’s Visual Model,” on page 65-19
The elements that make up a scene have parameters that help define them, for example a model filename. The set of parameters for a particular scene element is a schema. VR- Forces uses schemas to validate element definitions. You can create, copy, and delete schemas. For any schema, you can add and delete parameters and edit parameter values.
Changes to schemas are saved automatically. For more information, please see “Managing VR-Forces Settings,” on page 4-21.
Changes to element definitions do not take effect until you restart VR- Forces.
3DText
Animation
Channel Compass
Cockpit Display
ControlLine
ControlPoint
ControlPrism
Cuboid
Cylinder
Decal
DiGuyCharacter
EllipsoidArc
Entity
GreatCircleArc
GridLines
Line
ParticleSystem
Ribbon
RotorWash
SpeedTree
TacticalSmoke
Terrain
TidalStreamWake
Tree
Wake
Watercraft
WaterImpact
WidgetTheme.
To create a schema:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the Schema Editor page (Figure 81-1).
Figure 81-1. Schema Editor page
Click the Add button ( ) next to the Schemas label. The Create Instance dialog box opens (Figure 81-2).
Type a name for the new schema.
Click OK.
Add parameters as described in “Adding a Parameter to a Schema,” on page 81-7.
If a schema is used by a model definition, you cannot delete it. The Delete Schema button will be unavailable.
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the Schema Editor page (Figure 81-1).
In the Schemas list, select the schema you want to delete.
Click the Delete button ( ) next to the Schemas label. You are prompted to confirm the deletion.
Click Yes. The schema is removed from the list.
If you want a new schema that is a variant of an existing one, it can be easier to copy the existing schema and edit it than it is to create a new schema and add all of the parame- ters.
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the Schema Editor page (Figure 81-1).
Select the schema that you want to copy.
Click the Duplicate button ( ). The Duplicate Schema dialog box opens.
Type a name for the copied version of the schema.
Click OK.
The new schema is added to the list.
Edit the parameters as described in “Editing a Schema Parameter,” on page 81-8.
To add a parameter to a schema:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
In the Schemas list, select the schema to which you want to add a parameter.
Click the Add button ( ) next to the Entries label. A parameter called “key” is added to the parameter list (Figure 81-3).
Double-click “key”. The Rename Parameter dialog box opens.
Type a name for the parameter.
If the parameter has a specific type, click the value in the Type column and edit it.
If the parameter is required, click the value in the Required column and change it to True.
Optionally, add a description. The description provides context sensitive help on the element definition pages. To add a description:
Click the empty field in the Description column. The Edit Text dialog box opens.
Type the descriptive text.
Click OK.
!
!
If you delete a parameter from a schema, any element definitions that use the schema may become invalid. Invalid element definitions are shown in red in the list of definitions.
To delete a parameter from a schema:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the Schema Editor page (Figure 81-1).
In the Schemas list, select the schema from which you want to delete a parameter.
Select the parameter that you want to delete.
Click the Delete button ( ) next to the Entries label.
To edit a parameter for a schema:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the Schema Editor page (Figure 81-1).
In the Schemas list, select the schema for which you want to edit a parameter.
Click the parameter attribute that you want to edit. The attribute becomes edit- able.
Type the new attribute value.
Many of the visual definitions in an element definition have a model definition param- eter. A model definition specifies a set of parameters that are appropriate to the object type. (The parameters are determined by the model definition’s schema. For informa- tion about model schemas, please see “Creating and Editing Schemas,” on page 81-4.) For most VR-Forces users, the most important thing to know about model definitions is that for 3D models, the model definition specifies the 3D model, such as an Open- Flight file, that is used to display an entity. If you want to add new models to VR- Forces, you will probably have to create a new model definition for each one.
!
!
It is strongly recommended that you use the Simulation Object Editor to edit visual models, which includes the model definition.
VR-Forces comes with an extensive set of model definitions that are mapped to the included models. You can edit or delete these model definitions and you can create new ones.
Model definitions are created and edited on the Model Definition Editor page of the Visual Model Editors dialog box (Figure 81-4).
Figure 81-4. Model Definition Editor page
The model definitions provided with VR-Forces are stored in ./appData/defini- tions/ModelDefinitions. When you open the Visual Model Editors dialog box, it reads the files in this directory in alphabetical order. If files contain duplicate entries, the entry in the last file loaded takes precedence. You can use command line options to change the location of the model definitions that get loaded at startup. For details, please see “Importing Model Definitions from the Command Line,” on page 81-19.
The model definition for an entity includes the 3D model used to repre- sent it. You can change the model in the Visual Model Editors dialog box. However, you can also quickly and easily change the 3D model for an entity in the Simulation Object Editor. For details, please see “Editing a Simulation Object’s Visual Model,” on page 65-19.
Changes to element definitions do not take effect until you restart VR- Forces or reload the visual models. For information about reloading visual models, please see “Reloading Visual Models in the VR-Forces GUI,” on page 65-27.
You can also add model definitions in the Simulation Object Editor. However, you can only set the filename attribute.
A default VR-Forces installation has multiple model definition files. When you start VR-Forces they all get loaded. When you open the Visual Model Editors dialog box, all of the model definitions are listed. However, the editor does not keep track of which model definitions come from which model definition file. When you create or edit model definitions, VR-Forces does not automatically save them. Therefore, you are responsible for saving new and edited model definitions to the correct location.
The default model definition files are:
./appData/definitions/ModelDefinitions/AggregateLevelModel Definitions.ommx. Model definitions specific to aggregate-level scenarios.
./appData/definitions/ModelDefinitions/baseModel Definitions.ommx. Model defini- tions used by both entity-level scenarios and aggregate-level scenarios.
./appData/definitions/ModelDefinitions/coreModel Definitions.ommx. Model defini- tions for objects that do not have .entity files.
./appData/definitions/ModelDefinitions/EntityLevelModel Definitions.ommx. Model definitions for simulation objects in entity-level scenarios.
Before you add, delete, or edit a model definition, consider which of the following work flows best meets your need:
If you want to create new model definitions, the preferred work flow is to export them to a new file. This is the easiest way to avoid overwriting other model defini- tions files and makes them easily portable to newer releases of VR-Forces.
If you want to add the new model definitions to an existing model definitions file:
Replace the model definitions in the editor by using the Load and Replace option to load the model definition file you want to edit. (For details, please see “Importing Model Definitions,” on page 81-19.)
Add the new model definitions.
Export all changes back to the original model definition file.
If you have edited existing model definitions, you can export them to their original file or to a new file:
If you export to a new file, make sure that the file name is alphabetically later in alphabetical order than the original model definition file. This ensures that when the new model definition is loaded it will overwrite the original one.
If you want to export to the original model definition file:
Replace the model definitions in the editor by using the Load and Replace option to load the model definition file you want to edit. (For details, please see “Importing Model Definitions,” on page 81-19.)
Make your changes.
Export all changes back to the original model definition file.
If you want to delete a model definition, you must delete it from the source model definition file. Follow the work flow for editing an original model definition file.
For more information about how to export model definitions, please see “Exporting Model Definitions,” on page 81-20.
!
!
Do not use the Export All option if you are editing the combined model definition files that get loaded by default unless you are very certain about how you want to use the resultant file. If you export to a file in the
./appData/definitions/ModelDefinitions directory, it will conflict with the other
files in that directory.
!
!
VR-Forces does not save changes to model definitions automatically. If you want to keep changes, you must export them to a file.
Decide if you want to export the new model definition to its own file or to an existing file. (For details about the model definition work flow, please see “Work Flow Issues for Creating and Editing Model Definitions,” on page 81-10.)
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
If you want to export the new model definition to an existing file, use the Load and Replace procedure to load the file. (For details, please see “Importing Model Defi- nitions,” on page 81-19.)
Optionally, filter the model definitions in the list. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)
Click the Add button ( ) next to the Model Definitions label. The Add Model Definition dialog box opens (Figure 81-5).
Type a name for the new model definition.
!
!
Model definitions for DI-Guy characters must end with the letters DIG. Model definitions for SpeedTrees must end in ST.
Add parameters to the model, as described in “Adding Parameters to a Model Defi- nition,” on page 81-15.
Export the model definition. (For details, please see “Exporting Model Defini- tions,” on page 81-20.)
If you want to delete a model definition, you have to delete it from its original model definition file. Since the Visual Model Editors dialog box loads multiple model defini- tion files when it starts up, you must be sure that you only load the model definition file that you want to edit.
i If a model definition is being used, you cannot delete it.
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Click the Import and Replace button 
). The Import Model Definitions dialog box opens.
Select the model definition file you want to import.
Click Open.
Optionally, filter the model definitions in the list. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)
Select the model that you want to delete.
Click the Delete button ( ) next to the Model Definitions label. You are prompted to confirm the deletion.
Click Yes. The model definition is removed from the list.
Click the Export All button 
). The Export Model Definitions dialog box opens.
Select the model definitions file to save to.
Click Save.
If you want a new model that is a variant of an existing one, it can be easier to copy the existing model and edit it, than to create a new model and add all of the parameters.
!
!
VR-Forces does not save changes to model definitions automatically. If you want to keep changes, you must export them to a file.
Decide if you want to export the new model definition to its own file or to an existing file. (For details about the model definition work flow, please see “Work Flow Issues for Creating and Editing Model Definitions,” on page 81-10.)
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
If you want to export the new model definition to an existing file, use the Load and Replace procedure to load the file. (For details, please see “Importing Model Defi- nitions,” on page 81-19.)
Optionally, filter the model definitions in the list. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)
Select the model that you want to copy.
Click the Duplicate button ( ). The Duplicate Model Definition dialog box opens (Figure 81-6).
Type a name for the copied version of the model.
Click OK.
The new model definition is added to the list.
Edit the parameters as described in “Editing a Model Definition,” on page 81-15.
Export the model definition. (For details, please see “Exporting Model Defini- tions,” on page 81-20.)
By default, the Model Definition Editor page lists all models that VR-Forces knows about. You can filter the list to more easily work with a specific type of model.
To filter the list of model definitions, click the Filter button ( ) and select a schema type from the list.
You can add parameters to a model definition, you can delete parameters, and you can change their values. You can only add parameters that are appropriate to the schema type for a model.
!
!
VR-Forces does not save changes to model definitions automatically. If you want to keep changes, you must export them to a file.
When you create a new model definition, you must specify the parameters required by its schema. You can only add parameters that are permitted by the schema.
To add a parameter to a model:
Decide if you want to export the edited model definition to its own file or to an existing file. (For details about the model definition work flow, please see “Work Flow Issues for Creating and Editing Model Definitions,” on page 81-10.)
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
If you want to export the edited model definition to an existing file, use the Load and Replace procedure to load the file. (For details, please see “Importing Model Definitions,” on page 81-19.)
Optionally, filter the model definitions in the list. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)
Select the model for which you want to add a parameter.
Click the Add Parameter button ( ). A list of parameters is displayed (Figure 81-7).
Select the parameter you want to add. It is added to the parameter list.
Click the value for the parameter. The field becomes editable (Figure 81-8).
Type or select a value for the parameter.
Click away from the field.
When you have finished editing the model definition, export it. (For details, please see “Exporting Model Definitions,” on page 81-20.)
To edit a parameter:
Decide if you want to export the edited model definition to its own file or to an existing file. (For details about the model definition work flow, please see “Work Flow Issues for Creating and Editing Model Definitions,” on page 81-10.)
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
If you want to export the edited model definition to an existing file, use the Load and Replace procedure to load the file. (For details, please see “Importing Model Definitions,” on page 81-19.)
Optionally, filter the model definitions in the list. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)
Select the model for which you want to edit a parameter.
Click the value for the parameter you want to edit. The field becomes editable (Figure 81-8).
Change the value for the parameter.
Click away from the field.
When you have finished editing the model definition, export it. (For details, please see “Exporting Model Definitions,” on page 81-20.)
If you want to delete parameters from a model definition, you must export the changes back to the original file.
!
!
If you delete a parameter from a model definition, the definition may become invalid. Invalid model definitions are shown in red.
To delete a parameter from a model:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Use the Load and Replace procedure to load the model definition file that has the model definition you want to edit.
Optionally, filter the model definitions in the list. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)
Select the model from which you want to delete a parameter.
Select the parameter that you want to delete.
Click the Delete button ( ) next to the Entries label. The parameter is removed.
Export the model definition to the original model definition file using Export All. (For details, please see “Exporting Model Definitions,” on page 81-20.)
If you add, edit, or delete model definitions, you must explicitly export the new or updated definitions to a file. For details, please see “Exporting Model Definitions,” on page 81-20.
You can import model definitions and replace the loaded model definitions. You can import model definitions and merge them with the loaded model definitions. For details about how merging works, please see “Managing VR-Forces Settings,” on page 4-21.
To import model definitions and replace the existing definitions:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the Model Definitions page.
Click the Import and Replace button 
). The Import Model Definitions dialog box opens.
Select the model definition file you want to import.
Click Open.
To merge model definitions:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the Model Definitions page.
Click the Import and Merge button ( ). The Merge Model Definitions dialog box opens.
Select the model definition file you want to merge.
Click Open.
You can merge in model definitions with the --mergeModelDefs {directory | filename} command-line option. If you specify a directory, VR-Forces merges all model definition files in the directory. If you specify a file, it just merges that file. You can have multiple instances of this option in a command.
You can specify that VR-Forces not load the model definitions in the ./appData/defini- tions directory. To do this, start VR-Forces with the --noAppDataModelDefs command-line option.
You can export all model definitions and you can export individual model definitions. This allows you to create your own library of custom model definitions that you can easily migrate to newer releases of VR-Forces or copy to other VR-Forces installs.
!
!
The list of model definitions in a default VR-Forces installation is created by merging multiple model definition files. If you export all model definitions, they do not get exported back to their original files. They get exported to the file you select.
To export all model definitions:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Click the Export All button 
). The Export Model Definitions dialog box opens.
Select the model definitions file to save to or type a new file name.
Click Save.
To export selected model definitions:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Optionally, filter the model definitions in the list. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)
Select the model definitions you want to save.
Click the Export Selected button 
). The Export Model Definitions dialog box opens.
Select a file or type a name for the model definition file.
Click Save.
!
!
It is strongly recommended that you use the Simulation Object Editor to edit visual models, which includes the element definition.
Element definitions are organized in a tree-style hierarchy. At any level of the hierarchy an element definition inherits the visual definitions of its parents. This makes it possible to assign a visual definition to many elements at one time. You can change the inherited parameter values for a specific element at any level of the hierarchy. However, in most cases, you cannot delete an inherited visual definition.
You can create and edit element definitions. The procedures are the same for each element type except for the save procedure. Element definitions are not saved automat- ically. You must save them explicitly.
If you edit an element definition in the Simulation Object Editor and save the change, you can update an open scenario to use the new element definition. For details, please see “Reloading Visual Models in the VR-Forces GUI,” on page 65-27.
Entity, unit, and tactical graphics element definitions are stored in two types of files, a hierarchy file (.hier) and one or more leaf definition files (.leaf). The hierarchy file contains the hierarchy of categories for the element definitions, such as Entity Surface Boat and the attribute inheritance information associated with each level of the hierarchy. The leaf files contain the definitions for each element at the leaf level1.
Other types of element definitions do not save separate hierarchy and leaf files. They are saved to a file with the extension .elem.
When you add or edit entity, unit, and tactical graphics element definitions, you must save the changes to the hierarchy and leaf files separately. If you have only made leaf level changes, you do not have to save the hierarchy file.
Technically, the leaf level of a tree structure is a node with no children. For element definitions, the leaf level consists of specific definitions. A category that has no members would be part of the hierar- chy, not the leaf file.
You can create multiple hierarchy and leaf level files to meet your needs. However you can only load one hierarchy file at a time. When VR-Forces starts up, it loads the files in the various element definition directories. If it finds more than one hierarchy file for an element type, it only loads the first one (in alphabetical order). If it finds multiple leaf files, it loads them in alphabetical order. If there are any duplicate entries, the last file loaded takes precedence.
The element definitions for entity, unit, and tactical graphics are organized into multiple leaf files. This organization is to accommodate the different models in the AggregateLevel and EntityLevel SMSs. The element definitions are organized as follows:
./appData/definitions/Aggregate/ElementDefinitions. Element definitions for hierar- chical units such as platoons and companies:
EntityLevelAggregateElementDefinitions.leaf. Units used in entity-level scenarios.
coreAggregateElementDefinitions.leaf. Element definitions for objects that do not have .entity files.
AggregateLevelAggregateElementDefinitions.leaf. Units used in aggregate-level scenarios.
baseAggregateElementDefinitions.leaf. Unit elements used in both entity-level and aggregate level scenarios.
./appData/definitions/Entity/ElementDefinitions. Element definitions for individual simulation objects such as humans, ships, and cars:
EntityLevelEntityElementDefinitions.leaf. Element definitions used in entity-level scenarios.
coreEntityElementDefinitions.leaf. Element definitions for objects that do not have .entity files.
baseEntityElementDefinitions.leaf. Element definitions used in both entity-level and aggregate level scenarios.
./appData/definitions/TacticalGraphics/ElementDefinitions. Element definitions for tactical graphics:
EntityLevelTacticalGraphicsElementDefinitions.leaf. Tactical graphics used in entity-level scenarios.
coreTacticalGraphicsElementDefinitions.leaf. Element definitions for tactical graphics that do not have .entity files.
AggregateLevelTacticalGraphicsElementDefinitions.leaf. Tactical graphics used in aggregate-level scenarios.
baseTacticalGraphicsElementDefinitions.leaf. Tactical graphics used in both entity- level and aggregate level scenarios.
A default VR-Forces installation has multiple element definition files for entities, units, and tactical graphics. When you start VR-Forces they all get loaded. When you open the Visual Model Editors dialog box, all of the element definitions are listed. However, the editor does not keep track of which element definitions come from which element definition file.
Interaction, spot report, and smoke element definitions are loaded from just one file. They do not have hierarchy and leaf files. You cannot export specific element definitions. When you export them, all definitions get exported to the selected file. Therefore, except for the need to explicitly save all changes, the considerations in this section do not apply to them.
When you create or edit element definitions, VR-Forces does not automatically save them. Therefore, you are responsible for saving new and edited element definitions to the correct location. This section describes the issues to consider when you work with entity, unit, and tactical graphics element definitions to get the results you want and avoid problems.
If you have created new element definitions, the preferred work flow is to export them to a new leaf file. This is the easiest way to avoid overwriting other element definition files and makes them easily portable to newer releases of VR-Forces.
If you want to add the new element definitions to an existing element definitions file:
Load the hierarchy file. This removes all element definitions.
Load the element definition leaf file you want to edit.
Add the new element definitions.
Export all changes back to the original element definition leaf file.
If you have edited existing element definitions, you can export them to their orig- inal leaf file or to a new leaf file:
If you export to a new file, make sure that the file name is alphabetically later in alphabetical order than the original element definition file. This ensures that when the new element definition is loaded it will overwrite the original one.
If you want to export to the original element definition file, you must plan ahead:
Load the hierarchy file. This removes all element definitions.
Load the element definition leaf file you want to edit.
Make your changes.
Export all changes back to the original element definition file.
For more information about exporting element definitions, please see “Exporting Element Definitions,” on page 81-35.
!
!
Do not use the Export All Leaves option if you are editing the combined element definition files that get loaded by default unless you are very certain about how you want to use the resultant file. If you export to an existing element definitions file, it will conflict with the other files in that directory.
You can create new element definitions. Entity, unit and tactical graphics element defi- nitions get exported to .leaf files. Smoke, spot report, and interaction element defini- tions get exported to .elem files.
!
!
VR-Forces does not save changes to element definitions automatically. If you want to keep changes, you must export them to a file.
To create an element definition:
If you are adding an entity, unit, or tactical graphic element definition, decide if you want to export the new element definition to its own leaf file or to an existing file. (For details about the element definition work flow, please see “Work Flow Issues for Creating and Editing Element Definitions,” on page 81-23.)
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the page for the type of element definition that you want to create.
If you want to export the new element definition to an existing leaf file, use the Load and Replace procedure to reload the hierarchy. (This deletes all element defi- nitions.) Then load the element definition leaf file. (For details, please see “Importing Element Definitions,” on page 81-33.)
Expand the element definition hierarchy to the level at which you want to add an element definition and select the parent element (Figure 81-9).
Figure 81-9. Entity Definition Editor page
Click the Add button ( ). The Create Element Definition dialog box opens.
Type a name for the element definition. (You cannot edit the name after you create it, so try to avoid typing errors.)
Click OK. The new element is added to the list.
Optionally, edit the visual definitions assigned to the element. For details, please see “Editing a Visual Definition,” on page 81-27.
Optionally, add a visual definition to the element. For details, please see “Adding a Visual Definition,” on page 81-26.
Export the element definition. If you made any changes to an entity, unit, or tactical graphics hierarchy, you must export the hierarchy also. (For details, please see “Exporting Element Definitions,” on page 81-35.)
An element definition consists of a list of visual definitions for that element. You can add visual definitions and you can edit their parameters. In most cases, you cannot delete an inherited visual definition.
!
!
VR-Forces does not save changes to element definitions automatically. If you want to keep changes, you must export them to a file.
To add a visual definition to an element definition:
If you are editing an entity, unit, or tactical graphic element definition, decide if you want to export the edited element definition to its own leaf file or to an existing file. (For details about the element definition work flow, please see “Work Flow Issues for Creating and Editing Element Definitions,” on page 81-23.)
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
If you want to export the edited element definition to an existing leaf file, use the Load and Replace procedure to reload the hierarchy. (This deletes all element defi- nitions.) Then load the element definition leaf file. (For details, please see “Importing Element Definitions,” on page 81-33.)
Select the page for the type of element definition that you want to edit (Figure 81-9).
Select the element definition that you want to edit.
Optionally, on the Model Sets list, select the model set you want to use.
Click the Add button ( ) next to the Visual Definitions label. The Create Visual- izer Definition dialog box displays a list of available visual definitions.
Figure 81-10. Create Visualizer Definition dialog box
Select the visual definition that you want to add.
Click OK. The visual definition is added to the element.
Optionally, edit the parameters for the visual definition. For details, please see “Editing a Visual Definition,” on page 81-27.
When you have finished editing the element definition, export it. (For details, please see “Exporting Element Definitions,” on page 81-35.)
Visual definitions and their attributes are displayed either as gray italicized text or as black text (Figure 81-11). Italicized text indicates that the visual definition or attribute is inherited from a parent element. Visual definitions and attributes that are not itali- cized are particular to that element. (These entries could be inherited by child elements.)
Figure 81-11. Visual definition entry
To edit a visual definition parameter:
If you are editing an entity, unit, or tactical graphic element definition, decide if you want to export the edited element definition to its own leaf file or to an existing file. (For details about the element definition work flow, please see “Work Flow Issues for Creating and Editing Element Definitions,” on page 81-23.)
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the page for the type of element definition that you want to edit (Figure 81-9).
If you want to export the edited element definition to an existing leaf file, use the Load and Replace procedure to reload the hierarchy. (This deletes all element defi- nitions.) Then load the element definition leaf file. (For details, please see “Importing Element Definitions,” on page 81-33.)
Select the element definition that you want to edit.
In the Visual Definitions pane, click the value of the attribute that you want to edit. Depending on the attribute, a list of available values is displayed, a dialog box is displayed (Figure 81-12), or the field becomes editable.
For a list, select the new value. For an editable field, type a new value. For a dialog box:
If the dialog box window does not have a list, click the Add button ( ). A list of values is added to the dialog box window.
Select the value that you want.
Click OK.
When you have finished editing the element definition, export it. (For details, please see “Exporting Element Definitions,” on page 81-35.)
Mapping to Multiple Model Definitions or Schema
There may be cases where you want to map a visual definition to multiple model defini- tions or multiple schema. If you do this, VR-Forces randomly assigns the model defini- tion or schema to instances of the object.
To map a visual definition attribute to multiple values:
If you are editing an entity, unit, or tactical graphic element definition, decide if you want to export the edited element definition to its own leaf file or to an existing file. (For details about the element definition work flow, please see “Work Flow Issues for Creating and Editing Element Definitions,” on page 81-23.)
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the page for the type of element definition that you want to edit (Figure 81-9).
If you want to export the edited element definition to an existing leaf file, use the Load and Replace procedure to reload the hierarchy. (This deletes all element defi- nitions.) Then load the element definition leaf file. (For details, please see “Importing Element Definitions,” on page 81-33.)
Select the element definition that you want to edit.
In the Visual Definitions pane, click the value of the modeldefinition or modeldefini- tionschema parameter that you want to edit. A dialog box opens. If the attribute already has values, they are listed in the dialog box window as a series of lists (Figure 81-13).
Figure 81-13. Parameter with multiple values
To add a value, click the Add button ( ). A new list is added to the window.
Select a value from the new list.
To remove a value, click the Delete button ( ) next to the list for that value.
Click OK. The visual definitions list does not show all of the values, but clicking it opens the dialog box again and shows the selected values.
When you have finished editing the element definition, export it. (For details, please see “Exporting Element Definitions,” on page 81-35.)
Each visual definition has a set of attributes. Some of them may be optional, so they are not specified as part of the factory definitions. You can add optional attributes to a visual definition.
To add an attribute to a visual definition:
If you are editing an entity, unit, or tactical graphic element definition, decide if you want to export the edited element definition to its own leaf file or to an existing file. (For details about the element definition work flow, please see “Work Flow Issues for Creating and Editing Element Definitions,” on page 81-23.)
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the page for the type of element definition that you want to edit (Figure 81-9).
If you want to export the edited element definition to an existing leaf file, use the Load and Replace procedure to reload the hierarchy. (This deletes all element defi- nitions.) Then load the element definition leaf file. (For details, please see “Importing Element Definitions,” on page 81-33.)
Select the visual definition that you want to edit.
Click the Add Attribute button ( ). The Add Visualizer Definition Attribute window opens. It lists the attributes that are available for the visual definition (Figure 81-14).
Figure 81-14. Add Visualizer Definition Attribute window
Select the attribute that you want to add.
Click OK. The attribute is added to the visual definition.
Specify a value for the attribute. This might require typing a value, selecting a value from a list, or selecting a value in another window.
When you have finished editing the element definition, export it. (For details, please see “Exporting Element Definitions,” on page 81-35.)
You can delete individual attributes from a visual definition.
!
!
The Delete button above the list of visual definitions deletes entire visual definitions. Do not click it thinking it will delete just the selected attribute.
To delete an attribute:
If you are editing an entity, unit, or tactical graphic element definition, decide if you want to export the edited element definition to its own leaf file or to an existing file. (For details about the element definition work flow, please see “Work Flow Issues for Creating and Editing Element Definitions,” on page 81-23.)
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the page for the type of element definition that you want to edit (Figure 81-9).
If you want to export the edited element definition to an existing leaf file, use the Load and Replace procedure to reload the hierarchy. (This deletes all element defi- nitions.) Then load the element definition leaf file. (For details, please see “Importing Element Definitions,” on page 81-33.)
Select the visual definition that you want to edit.
Select the attribute that you want to delete.
Click the Delete Attribute button ( ).
When you have finished editing the element definition, export it. (For details, please see “Exporting Element Definitions,” on page 81-35.)
!
!
VR-Forces does not save changes to element definitions automatically. If you want to keep changes, you must export them to a file.
i You cannot delete an element definition if it is being used.
To delete an element definition:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the page for the type of element definition that you want to delete (Figure 81-9).
If you are deleting an entity, unit, or tactical graphic element definition, use the Load and Replace procedure to reload the hierarchy. (This deletes all element defi- nitions.) Then load the element definition leaf file. (For details, please see “Importing Element Definitions,” on page 81-33.)
Select the element definition that you want to delete.
Click the Delete button ( ) next to the Entity Definitions label.
Confirm the deletion.
Export the element definition back to the original element definition file. (For details, please see “Exporting Element Definitions,” on page 81-35.)
Changes to element definitions do not get saved automatically. You must explicitly export the changes to a file. For details, please see “Exporting Element Definitions,” on page 81-35.
You can import element definitions and replace the loaded element definitions. You can import element definitions and merge them with the loaded element definitions.
If you want to import entity, unit, or tactical graphics element definitions, you can import hierarchy files, leaf files, or both. If you import a hierarchy file, it removes all leaf file entries and replaces the previously loaded hierarchy.
When you import a leaf file, it is merged according to the criteria described in “Managing VR-Forces Settings,” on page 4-21.
You can also import or merge files in the legacy .elem format. If you import and replace entity, unit, or tactical graphics element definitions using an .elem file, the hierarchy and all element definitions are replaced with those in the elem file. If you merge an
.elem file, the merge is additive only. Entities with names that already exist are skipped.
i Interaction, smoke, and spot report element definitions use the .elem format.
You can replace the current hierarchy with a different one by importing a hierarchy file or a file in the legacy .elem format.
i When you import a hierarchy file, all leaf files are removed.
To import a hierarchy or element definition file and replace the existing definitions:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the page for the type of element definition you want to import.
Click the Import and Replace button 
). The Import Element Definitions dialog box opens.
Select the hierarchy file or element definition file (extension .elem or .hier) you want to import.
Click Open.
You can import and merge element definitions from leaf files or legacy element defini- tion (.elem) files.
i You cannot import a leaf file unless a hierarchy is already loaded.
To merge element definitions:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the page for the type of element definition you want to import.
Click the Import and Merge button 
). The Merge Element Definitions dialog box opens.
Select the element definition file (extension .elem or .leaf) you want to merge.
Click Open.
You can import and merge entity, unit, and tactical graphics element definitions when you start up VR-Forces using the following command-line options:
--entityDefsDir directory merges in all .hier and .leaf files in the specified directory. The directory must be ./appData/definitions/Entity/ElementDefinitions,
./appData/definitions/Aggregate/ElementDefinitions, or./appData/definitions/Tactical- Graphics/ElementDefinitions or be subordinate to one of them.
--mergeHierarchyEntityDef filename imports the specified .hier file.
--mergeLeafEntityDef filename merges in the specified .leaf file.
--mergeHierarchyTacticalGraphicsDef filename merges in the speci- fied tactical graphics .hier file.
--mergeLeafTacticalGraphicsDef filename merges in the specified tactical graphics .leaf file.
--mergeHierarchyUnitDef filename merges in the specified unit .hier file.
--mergeLeafUnitDef filename merges in the specified unit .leaf file.
These commands merge element definitions into the default element definitions, which are usually those in ./appData/definitions. You can also specify that the element defini- tions in ./appData/definitions not be loaded. In that case, only those files specified on the command line would get loaded. If none are specified, no element definitions would be loaded.
To specify that the element definitions in ./appData/definitions not be loaded, start VR- Forces with the --noAppDataEntityDefs, --noAppDataUnitDefs, or
--noAppDataTacticalGraphicsDefs command-line options.
Smoke, interaction, and spot report element definitions get exported to a file with the extension .elem. Entity, unit, and tactical graphics element definitions, get saved to separate hierarchy (.hier) and leaf (.leaf) files.
You cannot save portions of the hierarchy. The entire hierarchy gets exported to file.
When the Visual Model Editors dialog box loads entity, unit, and tactical graphics element definitions it merges several files. When you export all element definitions, they do not get exported back to these files. They get exported to the file you specify. If you keep the new file in the same directory as the installed files, there might be conflicts between them when VR-Forces loads element definitions. The element definition files are sorted into alphabetical order and loaded in that order. In the case of conflicts, the last file loaded wins. Therefore:
If you are only adding or editing a few element definitions, save them to one or more new leaf files rather than overwriting one of the default leaf files.
When you export to new leaf files, consider carefully how you name them.
When you export interaction, spot report, or smoke element definitions, all element definitions get exported to one file with the extension .elem.
To export interaction, spot report, or smoke element definitions:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the page for the type of element definition you want to export.
Click the Export All button 
). The Export Element Definitions dialog box opens.
Specify a file to export to.
Click Save.
If you want to export entity, unit, or tactical graphics element definitions, you must export the hierarchy and leaf information separately. If the hierarchy has not changed, you do not need to export it.
To export a hierarchy file:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the page for the type of element definition you want to export.
Click the Export Hierarchy button 
). The Export Element Definitions dialog box opens.
Select the hierarchy file you want to export to or type the name of a new file.
Click Save.
To export all definitions to a leaf file:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the page for the type of element definition you want to export.
Click the Export All Leaves button 
). The Export Element Definitions dialog box opens.
Select the leaf file you want to export to or type the name of a new file.
Click Save.
To export selected definitions to a leaf file:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the page for the type of element definition you want to export.
Select the element definitions you want to export.
Click the Export Selected Leaves button 
). The Export Element Definitions dialog box opens.
Select the leaf file you want to export to or type the name of a new file.
Click Save.
82. Mapping Models and Effects
This chapter explains how to map element definitions to DIS and HLA object types. Chapter F, Model Tutorials walks you through the process of adding a model.
Introduction to Object Type Mapping 82-2
Work Flow Issues for Creating and Editing Object Type Mappings 82-2
Adding an Object Type Mapping 82-4
Editing an Object Type Mapping 82-5
Filtering the Element Definition List 82-7
Deleting an Object Type Mapping 82-7
Saving Simulation Object Type Mappings 82-8
Importing Simulation Object Type Mappings 82-8
Exporting Simulation Object Type Mappings 82-9
Starting without Default Simulation Object Type Mappings 82-9
How VR-Forces Maps DI-Guy Models 82-10
In order to visualize a scene element (entity, unit, detonation, and so on), VR-Forces must map its object type enumeration to an element definition. This section explains how to do that.
When you add simulation objects and other scene elements in the Simulation Object Editor, it creates model definitions and handles object type mapping. Although this chapter explains all of the details of the Simulation Object Type Mappings dialog box, using the Simulation Object Editor to add simulation objects is the preferred method.
You map object types to element definitions in the Simulation Object Type Mappings dialog box. It has pages for mapping:
Cockpit displays.
Detonation effects.
Entities.
Firing effects.
Tactical graphics.
Tactical smoke.
Units.
The mapping process is the same for all object types. You can add new object type mappings, edit existing mappings, and delete mappings.
You can map more than one element definition to an object type. If you do this, when entities of this type appear in a simulation, VR-Forces randomly assigns one of the element definitions to the entity.
You can map an element definition to more than one object type.
A default VR-Forces installation has multiple object type mapping files. When you start VR-Forces they all get loaded. When you open the Simulation Object Type Mappings dialog box, all of the mappings are listed. However, the dialog box does not keep track of which mappings come from which mapping file. When you create or edit object type mappings, VR-Forces does not automatically save them. Therefore, you are responsible for saving new and edited mappings to the correct location.
The default model definition files are stored in ./appDate/definitions/<object_- type>/TypeMap, where <object_type> is Aggregate, Detonation, Entity, Fire, Smoke, or Tactical Graphics. Cockpit type mappings are in ./appData/settings/stealth/default_Cock- pitTypeMap.mhtx. Detonation, fire, cockpits, and smoke have one default mappings file. The other object types each have four files, which contain the following types of mappings:
Aggregate level mappings. Mappings for simulation objects in aggregate-level scenarios.
Entity level mappings. Mappings for simulation objects in entity-level scenarios.
Base mappings. Mappings for simulation objects used by both aggregate-level and entity-level scenarios.
Core mappings. Mappings for simulation objects for which VR-Forces does not have .entity files.
Before you add, delete, or edit a simulation object type mapping, consider which of the following work flows best meets your need:
If you have created new model mappings, the preferred work flow is to export them to a new file. This is the easiest way to avoid overwriting other mappings and makes them easily portable to newer releases of VR-Forces.
If you want to add the new mappings to an existing mappings file:
Use the Import and Replace option to load the mapping file you want to edit. (For details, please see “Importing Simulation Object Type Mappings,” on page 82-8.)
Add the new mappings.
Export all changes back to the original mapping file.
If you have edited existing mappings, you can export them to their original file or to a new file:
If you export to a new file, make sure that the file name is alphabetically later in alphabetical order than the original mapping file. This ensures that when the new mapping is loaded it will overwrite the original one.
If you want to export to the original mapping file:
Use the Import and Replace option to load the mapping file you want to edit. (For details, please see “Importing Simulation Object Type Mappings,” on page 82-8.)
Make your changes.
Export all changes back to the original mapping file.
If you want to delete a mapping, you must delete it from the source mapping file. Follow the work flow for editing an original mapping file.
For more information about how to export mappings, please see “Exporting Simulation Object Type Mappings,” on page 82-9.
To add an object type mapping:
Decide whether you want to save the new object type mapping to its own file or to an existing object type mapping file, as described in “Work Flow Issues for Creating and Editing Object Type Mappings,” on page 82-2.
Choose Settings Simulation Object Type Mappings. The Simulation Object Type Mappings dialog box opens.
Select the Entity Mapping Settings page (Figure 82-1). The page shows a list of object type enumerations in the Entity Type column. The entity definition mapped to the object type is listed in the Entity Definition column.
If you want to save the new object type mapping to an existing file, use the Import and Replace procedure to load the object type mapping file that you want to save to. (For details, please see “Importing Simulation Object Type Mappings,” on page 82-8.)
Click the Add button ( ). The Create New Entity Type Model Mapping dialog box opens (Figure 82-2). It lists a default object type enumeration.
Figure 82-2. Create New Entity Type Model Mapping dialog box
In the Entity Type text box, type the enumeration you want to map to a model. (Separate each value with a colon(:).)
In the Entity Definition list, select the entity definition that you want to map to this object type.
Click OK.
The new model mapping is added to the list.
Export the new model mapping to a new or existing file. (For details, please see “Exporting Simulation Object Type Mappings,” on page 82-9.)
This procedure describes how to edit an object type mapping for a simulation object. The procedure is the same for any page on the Simulation Object Type Mappings dialog box.
To edit an object type mapping:
Decide whether you want to save the edited object type mapping to its own file or to an existing object type mapping file, as described in “Work Flow Issues for Creating and Editing Object Type Mappings,” on page 82-2
Choose Settings Simulation Object Type Mappings. The Simulation Object Type Mappings dialog box opens.
If you want to save the edited object type mapping to an existing file, use the Import and Replace procedure to load the object type mapping file that you want to save to. (For details, please see “Importing Simulation Object Type Mappings,” on page 82-8.)
Select the model mapping that you want to edit. If you know the entity enumera- tion that you want to edit, you can type the enumeration in the Entity Type text box and click the Search button ( ). VR-Forces highlights the entry for that enumeration, if it is present.
To change the enumeration associated with an element definition:
In the Entity Type column, click the enumeration to make it editable.
Change the values of the enumeration.
Click someplace else in the window.
To change the element definition associated with an enumeration:
Optionally, filter the list of available element definitions. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)
In the Entity Definition column, click the element definition to make it an editable list (Figure 82-3).
Select the new element definition from the list.
Click someplace else in the window.
Export the model mapping to a new or existing file. (For details, please see “Exporting Simulation Object Type Mappings,” on page 82-9.)
You can filter the list of element definitions that are available in the Entity Definition (Figure 82-3) list for mapping to entity types.
Filtering does not change the list of simulation objects in the Entity Mapping Settings window. It just changes the list of simulation objects in the Entity Definition list when you change a specific mapping.
To filter the list of element definitions:
On any page of the Simulation Object Type Mappings dialog box, click the Filter button 
). A menu is displayed. A check mark indicates the type of element defi- nition that will be displayed when you make a element definition entry editable. (You may have to expand the hierarchy to see which elements are checked.)
Select the element definition type that you want to see in the list or select All to see all element definitions.
To delete an object type mapping:
Choose Settings Simulation Object Type Mappings. The Simulation Object Type Mappings dialog box opens.
Use the Import and Replace procedure to load the object type mapping file that you want to delete a mapping from. (For details, please see “Importing Simulation Object Type Mappings,” on page 82-8.)
Select the model mapping that you want to delete. If you know the entity enumer- ation that you want to edit, you can type the enumeration in the Entity Type text box and click the Search button ( ). VR-Forces highlights the entry for that enumeration if it is present.
Click the Delete button ( ).
Export the model mapping to the file you imported. (For details, please see “Exporting Simulation Object Type Mappings,” on page 82-9.)
New and changed simulation object type mappings do not get saved automatically. You must export them to the appropriate file. For details, please see “Exporting Simulation Object Type Mappings,” on page 82-9.
You can import simulation object type mapping files. An imported file replaces or merges with the previously loaded mappings.
!
!
When you merge type mappings, mappings from the file being merged in overwrite matching mappings that have already been loaded. If you have multiple models mapped to an object enumeration, all of the mappings are replaced by the new mappings.
To import simulation object type mappings:
Choose Settings Simulation Object Type Mappings. The Simulation Object Type Mappings dialog box opens.
Select the page for the type of simulation object whose mappings you want to import.
To replace the current set of mappings, click the Import and Replace button 
). The Import Mapping Settings dialog box opens.
To merge mappings, click the Import and Merge button ( ). The Merge Mapping Settings dialog box opens.
Select the settings file you want to import.
Click Open.
You must export all changes to simulation object type mappings. You can export all mappings to a file or you can select specific mappings and export them.
!
!
If you have not explicitly loaded and replaced the list of object type mappings, do not export them to an existing file. The existing file will be replaced either by all of the mappings loaded in the Simulation Object Type Mappings dialog box or by the selected object type mappings.
To export all simulation object type mappings to one file:
Choose Settings Simulation Object Type Mappings. The Simulation Object Type Mappings dialog box opens.
Select the page for the type of simulation object whose mappings you want to export.
Click the Export All button 
). The Export Mapping Settings dialog box opens.
Specify the file to export to.
Click Save.
To export selected object type mappings to a file:
Choose Settings Simulation Object Type Mappings. The Simulation Object Type Mappings dialog box opens.
Select the page for the type of simulation object whose mappings you want to export.
Click the Export Selected button 
). The Export Mapping Settings dialog box opens.
Specify the file to export to.
Click Save.
When you start VR-Forces, you can specify that it not load the entity, unit, or tactical graphics type mappings in ./appData/definitions or ./appData/settings/<application>. To do this, start VR-Forces with the --noAppDataEntityTypeMap,
--noAppDataEntityTypeMap, or --noAppDataEntityTypeMap command- line option.
83. 2D Icons, Cockpits, Wakes and other Visual Models
Chapter 81, Model and Element Definitions provides a general introduction to model schemas, model definitions, and element definitions. This chapter describes how to configure several specific types of visual models.
Editing Font-Based 2D Icons 83-2
Using Images for 2D Icons 83-4
Adding Images for Simulation Object Icons 83-9
Adding New Cockpit Display Models 83-10
Installing a Cockpit DLL 83-11
Creating a Model Definition for a Cockpit 83-11
Adding Object Models as Props 83-13
Adding a Category to the Props Palette 83-14
Configuring Tidal Stream Wakes 83-17
Adding Wind-based Controls to Models 83-18
Using Texture Atlases to Skin Models 83-19
Configuring Texture Mapping in the Model Definition 83-19
Metafiles for Texture Mapping 83-20
Flipping DDS Textures for a Model 83-21
Configuring SpeedTree Trees 83-22
Randomizing the Size of SpeedTrees 83-24
Best Practices for Creating Models for VR-Forces 83-26
The 2D icons in VR-Forces are configured in visual definitions. Font-based icons are configured in the Military Symbol Icon visual definition. Image-based icons use the Entity Image Symbol visual definition.
You can quickly change the 2D icon for a simulation object in the Simulation Object Editor. For details, please see “Editing a Simulation Object’s Visual Model,” on page 65-19.
To change a simulation object’s icon:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the Entity Definition Editor page (Figure 83-1).
Select the simulation object whose icon you want to edit.
In the Model Sets list, select 2D Icons.
To change the fill glyph:
Under the Military Symbology Icon visual definition, select the fillGlyph attri- bute (Figure 83-1).
Click the value in the Value column. The Choose Font Glyph dialog box opens (Figure 83-2).
Select the glyph with the fill pattern you want to use. Click OK.
To change the outline glyph, follow the same procedure as changing the fill glyph.
By default, VR-Forces uses TrueType fonts for 2D icons. You can replace the font-based icons with images using the Entity Image Symbol visual definition.
If you configure images for icons, be sure to save the element definitions to a file other than the default settings. If you revert to factory defaults or otherwise switch back to font-based icons and you have not saved the image mappings, you will not be able to recover them without repeating the entire mapping process again.
To use images for entity icons:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the Entity Definition Editor page (Figure 83-1). (If you want to change the icon for a unit, select the Unit Definition Editor page. To change the icon for a waypoint, select the Tactical Graphics page.)
In the Model Sets list, select 2D Icons.
In the Element Definitions list, select Entity. (If you are editing unit images, in the Element Definitions list select Aggregate. If you are editing tactical graphics images, in the Element Definitions list select Waypoint. For all other tactical graphics, skip to step 8.)
In the Visual Definitions list, select Military Symbology Icon (Figure 83-3).
Figure 83-3. Entity element definition with Military Symbology Icon visual definition
Click the Delete button ( ). The visual definition gets deleted.
Click the Add button ( ). The Create Visualizer Definition window opens. It displays a list of visual definitions (Figure 83-4).
Select Entity Image Symbol. (If you are configuring images for units, select Aggre- gate Image Symbol; for tactical graphics, select Tactical Graphic Image Symbol.)
Click OK.
In the Visual Definitions list, select Entity Image Symbol (Figure 83-5).
Figure 83-5. Entity element definition with Entity Image Symbol visual definition
Click the Add Attribute button ( ). The Add Visualizer Definition Attribute window is displayed (Figure 83-6).
In the attribute list, select parent.
Click OK. The parent attribute is added to the visual definition.
Click the value field to make it editable.
Type Main Model and press Enter.
In the attribute list, select type. The value is filled in automatically.
In the attribute list, select modeldefinitionschema. The Choose Supported Model Definition Schema dialog box opens (Figure 83-7).
Figure 83-7. Choose Supported Model Definition Schema dialog box
In the list, select WidgetTheme (Figure 83-8).
Figure 83-8. Completed Choose Supported Model Definition Schema dialog box
Click OK.
In the attribute list, select imagesymbolmap. The 2D Symbol Image Mapper dialog box opens (Figure 83-9).
Click the Add button. A list is added to the dialog box. It lists the forces for which you can map images. and the images that you can apply to a particular force
Select a force and an image from the lists (Figure 83-10).
Figure 83-10. 2D Symbol Image Mapper dialog box with force chosen
Add an entry for each force that you want to represent with an image.
Click OK.
In the attribute list, select destroyedsymbol. The destroyedsymbol attribute is added to the visual definition.
In the destroyedsymbol list, select Destroyed. The completed visual definition should look similar to Figure 83-11.
Figure 83-11. Entity Image Symbol visual definition
The settings for the Entity Image Symbol visual definition are inherited by each entity in the hierarchy from the base Entity definition. Unless you configure the various entity categories, all entities use the images you configured for the Entity category. Therefore, at a minimum, change the imagesymbolmap values for each force at each generic object type, such as Fixed Wing and Life Form, to use the proper image for that object type. Optionally, you can specify an image for each entity definition at the leaf level.
When you edit the Entity Image Symbol visual definition attributes, be sure that you select the 2D Icons model set.
VR-Forces includes a representative set of MIL-STD 2525a images. They are in
./data/images. If you want to add your own images, you can do so by adding a new model definition or changing the image mapping for an existing model definition. The new images are automatically added to the list of images for the imagesymbolmap in the Entity Image Symbol visual definition.
To add images for entities:
Copy the new images to ./data/images.
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
In the Schema list, select WidgetTheme.
If you want to change the image used for an existing model definition:
Select the model definition that you want to change, for example, 2525a_groundF.
Change the file specified for the backgroundImage attribute. If you want to specify an image for a new model definition:
Create a new model definition, as described in “Creating and Editing Model Definitions,” on page 81-9. It is recommended that you copy an existing model definition for a 2525a symbol.
Specify the image that you want to use for the new model definition.
VR-Forces supports cockpit displays created with GL Studio. A cockpit is implemented through a Reusable Software Object (RSO) DLL. A cockpit's values are changed through updaters. An updater is associated with a cockpit attribute through the cockpit model definition. Figure 83-12 shows the model definition for a cockpit.
Cockpit updaters are associated with an attribute name that is known to the RSO. The value you provide for a cockpit-specific attribute is the name of an updater for dynami- cally changing values or a constant value. Constant values are commonly used to configure a cockpit when it is loaded. VR-Forces provides a set of commonly used updaters. You can add additional updaters or override existing updaters through a plug- in.
The GL Studio license included with VR-Forces only covers the cockpits delivered with the product. If you add your own cockpits, you will need GL Studio run-time licenses.
Figure 83-12. Cockpit model definition
The general procedure for adding a new cockpit model is:
Install the cockpit’s DLL.
Create a model definition for the cockpit.
Map object types to the model definition, as described in “Adding an Object Type Mapping,” on page 82-4.
2D Icons, Cockpits, Wakes and other Visual Models — Adding New Cockpit Display Models
To install a new cockpit, place the DLL for the cockpit in ./data/Huds and create a model definition for it.
Cockpit models are configured using schemas and model definitions, just like any other model in VR-Forces. This section provides additional details specific to cockpits.
To create a model definition for a cockpit:
Add a new model definition, as described in “Creating a Model Definition,” on page 81-12. Be sure to select Cockpit Display as the schema. A new model defini- tion is added to the display (Figure 83-13). The message window lists the parame- ters that you must add. These are the parameters defined by the schema.
Add the required parameters, as described in “Adding Parameters to a Model Defi- nition,” on page 81-15. Table 83-1 describes the required parameters.
Table 83-1: Required parameters for cockpit models
Parameter Description
Parameter Description
Filename The name of the DLL without the file extension.
RSOName The name of the class to be loaded from the DLL. Default: filenameClass.
Perspective 2D or 3D. This parameter refers to the perspective of the cockpit display, not the terrain.
Table 83-1: Required parameters for cockpit models
Parameter Description
Parameter Description
PerspectiveWidth PerspectiveHeight
Adjusts the orthogonal projection for a 2D cockpit. Adjusts the perspective projection for a true 3D cockpit.
ChannelKeyword A keyword that tells a channel to display any object that has the keyword in its definition. Default: showCockpits. (This keyword means that any channel that has the showCockpits keyword will show cockpits.)
Offset X Offset Y Offset Z
Moves the cockpit offset around the screen. The OffsetX value shifts the cockpit left or right. The OffsetY value shifts it up or down. OffsetZ shifts a 3D cockpit forward and back. It has no effect on 2D cockpits.
Add the parameters required by the cockpit RSO. To do this, add an Attribute parameter, as follows:
Add an Attribute parameter, as described in “Adding Parameters to a Model Definition,” on page 81-15.
Double-click the parameter to make its name editable.
Add a colon and the name of an RSO attribute that you need to map. For example, Attribute:Heading.
In the Value column, click the value to make it editable. Type the name of an updater or specify a constant value in the format Value:value. You can specify an updater that you have added through a plug-in or one of the updaters provided with VR-Forces, as described in Table 83-2.
Map an object type to your definition, as described in “Adding an Object Type Mapping,” on page 82-4.
AOA Angle of Attack. Returns the pitch of the entity clamped (5 to 30 degrees).
FeetAGL Feet Above Ground Level. Returns the feet above the terrain (or buildings below).
FeetMSL Feet Above Mean Sea Level. Returns the altitude above the sea level.
FeetPerMinute Feet Per Minute. Returns the climb rate. KilometersPerHour Speed of the entity in kilometers per hour. MilesPerHour Speed of the entity in miles per hour.
KnotsPerHour Speed of the entity in nautical miles per hour.
Pitch Returns the pitch of the entity clamped (-180 to 180 degrees).
2D Icons, Cockpits, Wakes and other Visual Models — Adding Object Models as Props
Table 83-2: Updaters provided
Roll Returns the roll of the entity clamped (-180 to 180 degrees).
Yaw Returns the yaw of the entity clamped (0 to 360 degrees). Headlight Returns the headlight state of the entity as true or false.
Value This updater sends any value to the cockpit once and then never again. It is used to configure initial setup and to turn display components on or off.
Props are terrain objects that you can select independently of the terrain. “Extracting Props from a Terrain Patch,” on page 55-20 explains how to create them by extracting them from a terrain or a feature layer. You can also add props by creating model defini- tions for them. These props are added to the Props Palette and are then available to add to a terrain.
To add an object model as a prop:
Add a new model definition, as described in “Creating and Editing Model Defini- tions,” on page 81-9. Use the Entity, Tree, or SpeedTree schema, as appropriate. When you name the model definition, if you preface it with one of the categories on the Props Palette, such as Buildings, it automatically is placed in that category on the palette. For example, BuildingsMyBuilding puts MyBuilding in the Build- ings category.
Add the filename parameter.
Set the value for the filename to the location of your object model file. You can select any supported format. (Some formats, such as Collada (DAE) are not included in the file filter. To select such a format, choose All Files in the filters list.)
The list of categories on the Props Palette is controlled by the configuration file
./appData/settings/vrfGui/VRF3DTerrainPropCategories.xml. To add a new category, edit the file. The format should be obvious from examining the existing XML elements.
If you edit VRF3DTerrainPropCategories.xml, be sure to update the <count> element to reflect additions or deletions.
When dynamic ocean is enabled, VR-Forces simulates wakes on surface entities. Wakes are configured in the Ship Wake visual definition of an entity’s element definition. If you add your own model, you may want to change the default configuration values for its wake so that it more closely matches the dimensions and velocity of the object type being modeled.
You can also configure wakes in the Simulation Object Editor. For details, please see “Configuring Wakes,” on page 65-41.
To configure a ship wake in the Visual Model Editors dialog box:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Select the Entity Definition Editor page (Figure 83-14).
In the Element Hierarchy, expand the Entity list to the Surface level and select the entity that you want to configure.
In the Visual Definitions list, select and expand the Ship Wake visual definition.
Edit the parameters. Table 83-3 describes each parameter.
Table 83-3: Ship Wake visual definition attributes
Parameter Description
Parameter Description
beamwidth The width of the ship at its widest point.
bowsize The size of the bow in world units. This affects the wave- length of the bow wave and the initial spread of spray parti- cles at the bow. Use 0 for a pointy bow.
bowsprayoffset An offset from the ship position from which to emit spray
particles.
bowwaveoffset An offset from the ship position, along the direction of
travel, at which bow waves will originate.
bowwavescale A scaling factor for the bow wave's amplitude at the bow
of the ship.
draft The depth of the hull underwater.
hullsprayend The offset from the ship at which hull spray effects end.
Table 83-3: Ship Wake visual definition attributes
Parameter Description
Parameter Description
hullspraysizescale A scaling factor applied to the hull spray particles.
hullspraystart The offset from the ship at which hull spray effects begin. hullsprayvelocityscale The initial velocity of hull spray particles as a percent of the
ship velocity (0-1).
hullsprayverticaloffset A vertical offset to the starting point of new hull spray
particles.
maxbowwave The maximum amplitude of the bow wave, or -1.0 for
unbounded.
numhullsprays The number of spray particles emitted periodically along the
hull of the ship.
parent The visualizer’s parent.
propwashenabled Enable or disable propeller backwash effects. propwashoffset An offset from the ship position from which to generate
propeller backwash effects.
shiplength A value, that in combination with the entity’s speed, is
used to determine the length of the bow wake. sprayenabled If enabled, the wake emits spray particles.
spraysizescale A scaling factor applied to the size of the bow spray parti-
cles and their random spread.
sprayvelocityscale A scaling factor for spray effects at the bow of the ship.
This is applied to the initial velocity of the spray particles. sternwaveoffset An offset for the stern wakes.
type The type of visualizer.
wakeoffset An offset to the model’s origin that all other offsets are
relative to. Changing this offset lets you move all of the wake effects in tandem if the entity model changes.
Tidal stream wakes are supported as stand-alone models and are automatically attached to streamed buoys and beacons. Model definitions for wakes to be used with each of the supported buoy and beacon models are included (BuoysPillarWake, BeaconsLattice- Wake, and so on). You may want to edit them. We recommend wake lengths of at least 20m for best results. (Some of the model definitions specify values less than that.)
By default, VR-Forces starts with a tidal stream current speed of 0. To see tidal stream wakes, change the speed on the Scene Settings dialog box, Environment Conditions Settings page. For more information, please see “Configuring Marine Conditions,” on page 11-16.
2D Icons, Cockpits, Wakes and other Visual Models — Adding Wind-based Controls to Models
VR-Vantage can simulate the movement of flags and windsocks based on the current simulated wind speed and direction on terrains. It can also simulate movement of flags and windsocks on models added through connections or programmatically (this is not supported for props or external references). These features require models with appro- priate switches and articulations, as well as model-specific or terrain-specific metafiles.
For generic information about the metafile format and syntax, please see section 8.6, Transforming Nodes Programmatically, in VR-Forces Front-End Developers Guide.
The metafiles for windsocks and flags have sections that configure wind control of nodes, as follows:
Control switch nodes based on wind speed.
Control the heading (Z-Axis) of articulating (degree of freedom) nodes based on wind direction.
The metafile used for wind features supports two features — WindSwitchPart and WindDirPart.
WindSwitchPart. The WindSwitchPart feature is used to change the state of a switch node based on the current wind speed. The flag models used by MAK include a switch with three states. This feature has the following parameters:
WindSpeed. A list of wind speeds (in km/h).
WindState. A list of the switch state values that correspond to the values in the
WindSpeed parameter.
The number of items in each list should be the same (and only contain switch states supported by the node specified in the Linkage entry.
RotOffsetDeg. Allows a rotation offset to be applied.
RotDir. Indicates if the node should be rotated in a clockwise or counterclockwise direction.
Metafiles used to configure flags and windsocks include .\data\Terrain\Hawaii\Geom- etry\OpenFlightAlaMonana\AlaMoanaGeocentric.meta, .\data\Structures\Poles\Flag- Pole\FlagPoleFlag.meta, and .\data\Structures\Poles\WindSock.meta.
2D Icons, Cockpits, Wakes and other Visual Models — Using Texture Atlases to Skin Models
For example, VR-Forces has four different versions of the Airbus 320 jet, one each for American Airlines, British Airways, Lufthansa, and Singapore Airlines. Instead of having four geometry files with associated textures, you can use one geometry file for all four models and reference the appropriate texture in a texture atlas.
Texture skinning requires a MEDF (geometry) file and a texture atlas that has been prepared for the entities that will share the texture atlas. The portions of the texture for a given model are accessed via UV offsets into the texture atlas. This information is stored in a metafile (.meta) that references a .dtxc file. You must also specify the metafile in the model definition for each model that is to use it and a configName parameter that is used to identify the correct texture to use.
To use a texture atlas for a model, you must provide values for the metaFileName and
configName parameters in the model definition.
To configure texture mapping in a model definition:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Optionally, filter the model definitions in the list. (For details, please see “Filtering the List of Model Definitions,” on page 81-15.)
Select the model definition that you want to edit.
Click the Add Parameter button ( ). A list of parameters is displayed.
Select metaFileName. The metaFileName parameter is added to the model defini- tion.
In the value column specify the location of the metafile you want to use for this model.
Click the Add Parameter button and select configName. The configName parameter is added to the model definition.
In the value column type a string that VR-Forces should look for in the meta file to identify the texture pattern to use.
2D Icons, Cockpits, Wakes and other Visual Models — Using Texture Atlases to Skin Models
Export the model definitions.
VR-Forces uses metafiles to configure texture skinning. For conceptual information about metafile format and syntax, please see section 8.6, Transforming Nodes Program- matically, in VR-Forces Front-End Developers Guide.
A metafile is associated with a terrain or model in one of the following ways:
Place it in the same directory as the terrain or model's MEDF file. The meta file must have the same name as the MEDF file, but with a .meta extension.
Specify it in the metaFileName parameter of the model definition used to import the model.
VR-Forces metafiles support two features that are relevant to texture mapping:
UvAtlasMapper. Defines a texture atlas for texture skinning.
SwitchStateMapper. Specifies the child of a switch node to use. For example you could have an M1A1 with mine rollers, with mine plows, or DU armor, depending on the switch node used.
The following example shows the meta file for the Airbus 320 jet Airbus320a.meta:
{
"NodeFeatures": [
{
"Linkage": {
"Comment": "Traversal with match up this feature based on NodeName match OR AnnotationName match",
"NodeName": "",
"AnnotationName": "@dis annotation texture"
},
"FeatureData": [
{
"FeatureName": "UvAtlasMapper",
"AtlasFile": "$(DATA_DIR)\\Vehicles\\FixedWing\\Airbus320a\\ Airbus320a.dtxc",
"Mappings": [
{
"ConfigName": "AmericanAirlines", "AtlasKeys": {
"Pattern": "AmericanAirlines"
}
},
{
"ConfigName": "BritishAirways", "AtlasKeys": {
"Pattern": "BritishAirways"
}
},
{
"ConfigName": "Lufthansa", "AtlasKeys": {
"Pattern": "Lufthansa"
}
2D Icons, Cockpits, Wakes and other Visual Models — Flipping DDS Textures for a Model
},
{
"ConfigName": "SingaporeAirlines", "AtlasKeys": {
"Pattern": "SingaporeAirlines"
}
}
]
}
]
}
]
}
When VR-Forces loads an Airbus 320, the metaFileName parameter in the model defini- tion points it to the Airbust320a.meta file. The configName parameter in the model defi- nition specifies which texture to use, for example, AmericanAirlines. VR-Forces reads Airbust320a.meta and associates the configName string, with the pattern value, also AmericanAirlines. Then it looks in Airbus320a.dtxc and gets the UV offset of Ameri- canAirlines so it knows which textures to use from the texture atlas.
The UV offsets for these models are configured in Airbus320a.dtxc. (The file contains explanatory comments.)
texture,COLPAT,AmericanAirlines,0.0,0.0 texture,COLPAT,Lufthansa,0.0,0.189612 texture,COLPAT,SingaporeAirlines,0.0,0.344823 texture,COLPAT,BritishAirways,0.0,0.500039
If a model is displayed upside down because its DDS textures are not what VR-Forces expects, you can specify that the model be flipped. (For more information about DDS textures, please see “Displaying DDS Textures Correctly,” on page 61-10.)
To flip DDS textures for a model:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Optionally, filter the model definitions in the list.
Select the model for which you want to change the DDS parameter.
If the model has the flip DDS textures parameter in its parameters list, set it to 1.
If the model does not have the flip DDS textures parameter in its parameters list, click the Add Parameter button ( ) to see if this is a valid parameter for this model. If it is, you can add the parameter and set it to 1.
Export the updated setting.
SpeedTree trees are high resolution models of trees. To improve performance, you can set clipping plane and level-of-detail (LOD) values to vary the resolution of the trees placed in the scene based on their distance from the observer. For details about clipping planes, please see “Setting the Clipping Planes,” on page 77-9. Table 83-4 describes the settings you can change.
Table 83-4: SpeedTree settings
Parameter Description
Parameter Description
Clipping distance The distance at which trees are clipped out of the scene.
Fade from High LOD to Low LOD The range (near to far) in which high
LOD trees are gradually replaced with low LOD trees.
Fade from Low LOD to Billboard The range (near to far) in which low
LOD trees are gradually replaced with billboard trees. This range is usually greater than the range for high LOD to low LOD.
Ambient Scalar Multiplies the built-in ambient lighting value in each SpeedTree by the speci- fied amount.
Diffuse Scalar Multiplies the built-in diffuse lighting value in each SpeedTree by the speci- fied amount.
Specular Scalar Multiplies the built-in specular lighting value in each SpeedTree by the speci- fied amount.
To configure SpeedTree trees:
Choose Settings Display. The Display Settings dialog box opens.
Select the SpeedTree Settings page (Figure 83-15).
Update parameters as desired.
Click Close.
If a SpeedTree is a prop, it is scaled as the product of the following settings:
The scale attribute in its model definition. If the scale attribute is not part of the model definition, the value defaults to 1.0.
A random scale factor as specified on the SpeedTree Randomization page on the Terrain Settings dialog box, if enabled.
A feet-to-meters conversion factor of 0.3048.
If a SpeedTree is a streamed in using an earth file, it is scaled as the product of the following settings:
The scale attribute in its model definition. If the scale attribute is not part of the model definition, the value defaults to 1.0.
The marker-scale attribute in the model element that configures the trees.
A random scale factor as specified on the SpeedTree Randomization page on the Terrain Settings dialog box, if enabled.
A feet-to-meters conversion factor of 0.3048.
You can also randomize the orientation of SpeedTrees.
To specify randomization of SpeedTree scaling:
Choose Settings Terrain. The Terrain Settings dialog box opens.
Select the SpeedTree Randomization page (Figure 83-16).
To enable randomization of the SpeedTree scale, select the Enable SpeedTree Scale Randomization check box.
If you enabled Enable SpeedTree Scale Randomization, specify values for the Minimum Tree Scale and Maximum Tree Scale.
To enable randomization of tree orientation, select the Enable SpeedTree Orienta- tion check box.
2D Icons, Cockpits, Wakes and other Visual Models — Best Practices for Creating Models for VR-Forces
Keep all textures to powers of two, for example 256x256, 128x512, or 2048x2048:
Make sure textures use as many of the pixels as possible and that there are no large black areas in the texture.
Keep alpha (transparency) to a minimum.
Minimize the number of textures:
Create a texture atlas that uses multiple textures combined into one.
Group polygons together that use the same texture.
Use the same textures for all LOD nodes.
Minimize the number of nodes:
Keep the hierarchy as flat as possible.
Move all LOD nodes to the top of the hierarchy.
When you reuse geometry in the model, use instancing.
Minimize the number of polygons that have different attributes:
Use the same material on polygons whenever possible.
Use two polygons with flipped normals instead of using the double sided attri- bute.
Use the same color on polygons whenever possible.
Group polygons with similar attributes.
Consider using a more aggressive LOD structure:
Reduce the switchout distance to be smaller so that the LODs switch sooner.
Minimize the number of LODs.
Make sure that models switch out completely at a reasonable distance.
Reduce the number of external references:
Merge external reference files.
Create instances from external merged reference files.
2D Icons, Cockpits, Wakes and other Visual Models — Compressing Model Files
The models and image files provided with VR-Forces are shipped in compressed formats (MÄK Encrypted Data Format (MEDF) and MÄK Encrypted Image Format (MEIF)). You may want to compress your models to save space or protect intellectual property. You can convert supported formats to MEDF and MEIF with
./bin64/medfTool.exe. The compression tool supports the 3D modeling formats
supported by VR-Forces, such as OpenFlight, 3DS, and OBJ, and raster formats such as RGB and PNG.
When VR-Forces processes a request to load a a file, such as an external reference in a terrain, it checks the cache and the directory of the requested file for an MEDF version of the file. If it does not exist, it loads the file in the original format.
The syntax for medfTool is as follows:
medfTool [-q simple_filename ... -p <integer> -s directory
... -z optimization -i -o -m extensions ...
-x extensions ... --norecurse --directory directory
-f filename -- -v -h]
Table 83-5 describes the arguments.
Table 83-5: medfTool arguments
Argument Description
Argument Description
(-- | --ignore_rest) Ignore all arguments after this one.
--directory directory Specifies the directory to search for image and geometry
files to convert into MEDF and MEIF. All subdirectories are visited unless the --norecurse command line option is used.
(-f | --file) filename Convert just this file. The extension of the file must be
specified using -x or -m to indicate it is an image or a geometry file.
(-h | --help) Displays usage information.
(-i | --ignore_errors) Ignore errors in the encryption process and continue
without exiting.
(-m |
--image_exten- sions) extension
Specifies the extensions of image formats which will be converted into MEIF format. Use this argument to encrypt a directory. Can be used multiple times.
--norecurse Do not recurse through subdirectories. Default: recurse
through subdirectories.
(-o | --onlyIfNew) Only generates an encrypted file if the expected output
file does not exist.
2D Icons, Cockpits, Wakes and other Visual Models — Compressing Model Files
Table 83-5: medfTool arguments
Argument Description
Argument Description
(-p | --threads)
threads
(-q | --forceOpaque)
simple_filename
(-s | --search)
directory
Specifies the number of threads to run. Specifying zero results in the number of threads equaling the number of logical processors the host machine has.
Specifies a filename and extension, but no path, to force polygons with these filenames to be opaque. Accepted multiple times.
Adds a directory to the search path when resolving external references. During processing, any external references not found are removed from the generated files. Files in the search path are not converted.
(-v | --version) Display version information and exit.
(-x | --extensions)
extension
(-z | --optimize)
optimization
Specifies the extensions of geometry file formats that will be converted into MEDF format. Use this argument to encrypt a directory. Can be used multiple times.
Specifies the optimization level. Maximum optimization may provide better optimization than the default setting, but it is significantly slower. Possible values are:
0 = None.
1 = Default.
2 = Maximum optimization.
The following example recursively compresses all FLT, RGB, RGBA, PNG, and DDS files in %MAK_DATADIR%/Terrain:
./bin64/medfTool.exe
--directory %MAK_DATADIR%/Terrain --extensions flt
--image_extensions rgb --image_extensions rgba
--image_extensions png --image_extensions dds
The following example compresses all FLT, RGB, RGBA, PNG, and DDS files in
%MAK_DATADIR%/Lifeforms. It does not compress files in subdirectories.
./bin64/medfTool.exe
--directory %MAK_DATADIR%/Lifeforms --norecurse
--extensions flt --image_extensions rgb
--image_extensions rgba --image_extensions png
--image_extensions dds
84. Configuring Emitter Volumes
This chapter explains how to configure display of emitter volumes. For information about how to configure simulation of emitters, please see Chapter 74, Configuring Emitters and Radios.
Configuring Emitter Volumes 84-2
Configuring Emitter Volume Color 84-2
Controlling Emitter Volume Radius 84-3
Configuring Emitter Volume Segments 84-4
You can configure how VR-Forces colors emitter volumes, how they are drawn, and how they are scaled for visibility. You can configure emitter volumes by editing the DefaultEllipsoidArc model definition or by creating customized ellipsoid arc model definitions and applying them to different entity models.
In order for an entity to display emitter volumes in 2D observer modes and 3D observer modes, it must have a 2D Emitter Volume visualizer in its 2D model set and 3D Emitter Volume visualizer in its 3D model sets. The DefaultEllipsoidArc model definition is an attribute of the visualizer.
By default, emitter volumes are displayed using fixed colors for high frequency and low frequency. You can configure emitter volumes to be colored based on the emission frequency or pulse rate. When emitter volume color represents frequency, color is deter- mined by the frequency field of the EM Emission update message. In both cases, you specify a low frequency or pulse rate value and a high value.
If the emitter frequency or pulse rate is lower than your specified low value, the emitter volume is red. As frequency rises above the specified low value, emitter volume color changes, progressing through the colors of the visible spectrum until the specified high value is reached. At the high value and above, the emitter volume is violet.
To change coloring from the default, you must add the appropriate attributes to the emitter volume visualizer for the entities whose model definitions you want to change. Table 84-1 describes the emitter volume visualizer attributes that affect emitter volume color.
Table 84-1: Emitter volume visualizer attributes
Attribute Description
Attribute Description
colorByFrequency If True, color by frequency instead of using static
colors.
lowFrequency The low frequency threshold for coloring by frequency.
Default: 800 MHz.
highFrequency The high frequency threshold for coloring by frequency.
Default: 1 GHz.
usePulseFrequency If colorByFrequency is True and usePulseFrequency is
True, color emitter volumes by pulse frequency.
lowPulseFrequency The low pulse rate threshold for coloring by frequency.
Default: 100 Hz.
highPulseFrequency The high pulse rate threshold for coloring by frequency.
Default: 3 KHz.
A emitter volume’s radius (that is, the distance it extends from the emitter) is based in part on emitter power and in part on elevation and azimuth sweep data obtained from EM-Emission state messages. A higher emitter power value results in a longer radius, while a wider field of view results in a shorter radius (because the radiated power is distributed over a wider area).
If VR-Forces relied exclusively on these values, the range of sizes among different emitter types could become too wide to be practical, with some emissions being barely visible, and other emissions covering the entire virtual world. Therefore, a configurable exponent weight and scale factor have been added to help fine tune the emitter beam radii. The radius exponent weight (a value between 0 and 1) slows the growth of the radius when power or area is greater than 1 and increases the growth of the radius when power or area is less than 0. The scale factor increases the radii of all beams by the given value.
To change the scale factor and exponent from the default, you must add one or both of the following attributes to the emitter volume visualizer for the entities whose model definitions you want to change:
linearScale. The amount of linear scaling applied to all emitter volumes. Default: 100.
exponentialScale. The amount of exponential scaling applied to emitter volumes. Default: 0.1.
VR-Forces calculates emitter volume radius by approximating the spread of the emis- sions based on the elevation and azimuth sweeps. If the approximate coverage is zero, it sets the value to 1. Then it applies the linear and exponential scaling values. The code for implementing this is as follows:
double tempVar = 8*elevationSweep*sin(2*azimuthSweep); if (tempVar <=0) tempVar=1.0;
scale = linearScale * pow(sqrt(power/tempVar), exponentialScale );
field of view, VR-Forces draws one segment. Figure 84-1 shows segments set to 10o (the default) and 30o.
10o 30o
Figure 84-1. Emitter volume segments
Emitter volume segments are managed by the EllipsoidArc schema and model defini- tions based on it. VR-Forces ships with one ellipsoid arc model definition – DefaultEl- lipsoidArc. You can edit this model definition or create copies of it and customize them. If you want to have different emitter volumes for different entities, assign a different ellipsoid arc model definition to each one.
To specify the segment angle:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Click the Filter button 
) and select EllipsoidArc. The ellipsoid arc model defini- tions are listed in the window.
Select DefaultEllipsoidArc (Figure 84-2).
Change the value of the angleSegmentMax parameter. The minimum value is 10 (degrees); the maximum is 45.
Export the updated setting.
Off
On
Figure 84-3. Segment outlines
To display or hide segment outlines:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Click the Filter button 
) and select EllipsoidArc. The ellipsoid arc model defini- tions are listed in the window.
Change the value of the showLines parameter.
Export the updated setting.
If you want to customize the segment angle and segment outlines for a particular entity without changing the values for other entities, you must create a separate ellipsoid arc model definition and add it to the entity’s model definition.
To create a custom ellipsoid arc model definition:
Choose Settings Visual Model Editors. The Visual Model Editors dialog box opens.
Click the Filter button 
) and select EllipsoidArc. The ellipsoid arc model defini- tions are listed in the window.
Select DefaultEllipsoidArc.
Click the Duplicate Model Definition button ( ). The Duplicate Model Defini- tion dialog box opens with a default definition name.
Accept the generated name or type a new name for the model definition.
Click OK. The model definition is added to the list.
Change the parameter values for the new model definition as desired.
Select the Entity Definition Editor page.
Select the entity whose emitter volume you want to change.
Select the 3D Sensor Volume visualizer for the entity.
Click the Value column for the modeldefinition attribute. The Choose Model Defini- tion dialog box opens. It has a list of model definitions.
Select the model definition that you just created.
Click OK.
Export the updated setting.
If you are connected to an exercise, disconnect and then reconnect to enable the new model definition.
85. The WRM Specification (DIS Notes)
Some OpenFlight files contain information specified by the WRM Entity Model Specification for DIS Interoperability. This information makes it possible for VR-Forces to depict the state of an entity's articulated and attached parts correctly and to switch among different entity appearances.
This chapter contains information that can help you build entity models that comply with the WRM specification, or add that compliance to existing models.
The WRM specification was developed by MÄK Technologies (now VT MAK), Para- digm Simulation Inc., MultiGen Inc., and SAIC, for the ARPA War Breaker project. (Paradigm Simulation and MultiGen merged and were later acquired by Presagis.)
Although the WRM specification was developed for DIS, it is used in the HLA RPR FOM.
The OpenFlight File Format 85-3
Node Name and Comment Fields 85-3
External References and Instancing 85-3
Modeling for DIS Interoperability 85-3
The DIS Attribute Lexicon (DAL) 85-4
The WRM Specification (DIS Notes) — Introduction
In order for visualization applications such as VR-Forces to change the state of a model in response to network messages, they must have certain information about the model. For example, which piece of the model’s geometry is associated with which articulated part, and which piece of a model is associated with a particular entity appearance attri- bute.
This chapter describes a method of encoding information in an OpenFlight format model so that applications can make these associations. For the most part, information is associated with a MultiGen node by including it as a comment associated with the node. Comments that contain this information begin with the token, @dis.
Although VR-Forces implements only a subset of the functionality enabled by the WRM Model Specification, we recommend that models conform to as much of the specification as is appropriate for the model, to promote compatibility with future versions of VR-Forces, and with visualization applications from other vendors.
The OpenFlight file format organizes geometry into the following types of nodes:
Face nodes represent individual polygons.
Object nodes represent face nodes that are logically or geographically related. Object nodes can have only face nodes (polygons) as children.
Level of detail (LOD) nodes provide a means to select alternate geometries based on a user-definable range. Using lower resolution geometry for objects that are far from the observer saves memory and improves performance.
Degree of Freedom (DOF) nodes specify translational or rotational freedom, or both, for portions of a model. They can be used for DIS articulated parts or animated special effects. They specify a type of transformation and its limits, such as “rotate about the x axis between 45 and 135 degrees”. The OpenFlight approach to degrees of freedom is hierarchical.
Group nodes represent logically-related or geographically-related object nodes. Group nodes are the most general, and may have any type of nodes, except face nodes, as children.
Each node contains a comment field for user-definable data. The WRM Specification defines keywords that, when placed in a comment field, provide the information that DIS applications need to properly render a model.
The following OpenFlight constructs provide a means to avoid duplicating massive amounts of geometry:
An external reference (or xref) is a pointer to another OpenFlight file that contains additional geometry.
A transformation matrix is usually attached to an xref to locate the position and orientation of the referenced object’s coordinate system geometry. Each instance may have a transformation matrix controlling the position and orientation of the child’s coordinate system.
The WRM Specification provides uniform standards for locating and orienting the model coordinate system and a way to map DIS codes to associated models and parts. By conforming to these standards, applications that support the WRM Specification do not need customized software to interpret the multiple potential model formats that might otherwise exist.
DIS attributes are specified using the following syntax:
@dis keyword values # comment
where:
@dis must precede the keyword.
keyword is one of the DAL keywords.
values can be a number or string. Depending on the requirements of the keyword, the values specified can be an individual value, a comma separated list, or a range.
# indicates the start of a comment. Comments are case sensitive. A comment continues until the next @dis entry.
Remember that all comments will be parsed by VR-Forces, so spelling counts.
The WRM Spec supports the following keywords:
This keyword is always followed by the switch keyword.
switch appearance. Identifies a model appearance attribute with a DIS keyword. This keyword is placed in a Switch node in the model above the geometry that is going to be switched.
state state,state... . Specifies the state of the appearance attribute with a DIS appearance state code. This keyword is placed in a Group node just below the switch node. For a list of supported values, please see Table 85-6.
OpenSceneGraph (OSG) and the DIS Standard use different right-hand coordinate systems. Table 85-1 describes the two systems. Figure 85-1 illustrates them.
Table 85-1: Model coordinate systems
Coordinate | OpenSceneGraph | DIS |
X | Right | Forward |
Y | Forward | Right |
Z | Up | Down |
Z
X Y
Y X
Z
OSG coordinate system DIS coordinate system
Figure 85-1. Model coordinate systems
When you create models, it is recommended that you use the OpenSceneGraph coordi- nate system. The simulation application will convert the coordinates, as follows:
xmodel = yDIS.
ymodel = xDIS.
zmodel = -zDIS.
The origin of the model’s coordinate system should be located as follows, depending on the domain of the entity:
Land: on the base of the vehicle, on the axis of yaw rotation.
Surface: On the axis of the center of buoyancy, in the plane of the waterline for unloaded ship.
Subsurface: On the axis of the center of buoyancy, in the plane of the waterline for surfaced submarine.
Air and Space: At the center of gravity.
Figure 85-2 illustrates the location of a model’s origin for each platform domain.
Land
Z
Y
X
On the plane of ground contact, at the axis of yaw rotation.
Air Z
Y
X
At the center of gravity.
Surface
Z
Y
X
On the axis of the center of buoyancy, in the plane of the waterline for an unloaded ship.
Subsurface Z
Y
X
On the axis of the center of buoyancy, in the plane of the waterline of a surfaced submarine.
Space Z
Y
X
At the center of gravity.
Figure 85-2. Location of origin by domain
The WRM Specification (DIS Notes) — Articulated Parts
In order for VR-Forces to properly depict the state of articulated parts, models must conform to the following specifications:
There must be one DOF node for each articulated part. (This means that if there are several LODs, they should be children of the DOF.) Each articulation DOF should be a descendant of the DOF for the part to which it is attached (unless the parent part is just the base model itself). For example, the DOF for a gun should be a descendant of the DOF for a turret.
Each articulated part DOF node must have all of the geometry and other nodes associated with the part underneath it. This DOF node must have a comment asso- ciated with it. The comment must be of the form:
@dis articulated_part part-number
where part-number is the enumeration for the particular type of part that this part of the model represents. For example, the part number of a turret is 4096, and the part number of a gun is 4416.
Therefore, the child group of a turret’s DOF must be commented with:
@dis articulated_part 4096
The child group of a gun’s DOF must be commented with:
@dis articulated_part 4416
The WRM Model Specification specifies that information about the legal motions of each articulated part be encoded in the comment field. Currently, VR-Forces does not use this information.
Do not include static offsets in the DOF attributes. That is, when you set all of the DOF parameters (X, Y, Z, heading, pitch, roll) to 0, the model should appear in its neutral position.
Switch nodes are used to represent a choice between several different children, based on a particular appearance attribute.
We define a switch node as a group node with a comment of the form:
@dis switch attribute
where attribute is the name of the attribute that should be used to select a child. (For example, damage, smoke, hatch, and so on.)
The children of the switch node represent the different portions of a model among which VR-Forces will select, based on the appearance attribute. If a switch node is commented with:
@dis switch hatch
it may, for example, have three children containing geometry for a closed hatch, popped hatch, and open hatch.
These children of the switch node must be commented so that VR-Forces knows which child matches which values of the appearance attribute. The comment is of the form:
@dis state value-list
value-list is of the form m[,m]+ where m is one of the following:
An integer representing the enumeration of a value that an appearance attribute may take on, for example, 1 for hatch closed.
Two integers, a and b, separated by a hyphen, representing all enumerations from a through b, for example, 2-5 for all states whose enumerations are 2, 3, 4, or 5.
The integer -1, which indicates that this child is the default child, to be used when the attribute state matches no values in any children.
For instance, the child of the hatch switch node that represents a closed hatch might be used when the hatch attribute value is either 0 (not-applicable), 1 (closed), or any value other than those enumerated in other children. This child would be commented:
@dis state 0,1,-1
The child with the popped hatch geometry should be used when the value is 2 (popped) or 3 (popped with person visible) and is commented:
@dis state 2,3
The child that contains the open hatch geometry should be used when the value is 4 (open) or 5 (open with person visible) and is commented:
@dis state 4,5
There may be many switch nodes for the same attribute. For example, there may be several pieces of a tank’s geometry that are affected by the destroyed attribute.
The WRM Specification (DIS Notes) — Entity Appearances
In Figure 85-3, the turret DOF node is attached to the body Group node. The barrel, gun, and hatch DOF nodes are attached to the turret. This allows the turret to be posi- tioned in the coordinate system of the body, and the barrel, gun, and hatch to be posi- tioned in the coordinate system of the turret.
This model also contains a switch node that is flagged with animation. The comment on this node is @dis switch moving. This switches between two Group nodes – Stop and Go. Under the Stop node there is a single mesh of the treads of the tank.
Under the Go node there is a Group node, with the animation flag set on. This creates a flipbook animation of all nodes below this Group node. There are three meshes in different states of moving: Frame 1, Frame 2 and Frame 3. At runtime OpenScene- Graph will animate these meshes when the velocity is not 0.
If multiple color schemes are needed to represent camouflage, winter, and desert versions, another switch is needed.
Figure 85-3. 3D model structure
The WRM Specification (DIS Notes) — Animation
By default, animation sequences are displayed as quickly as possible. However, you can configure the animation sequence rate using a WRM animation comment in the animation node's comment field.
The comment syntax is as follows:
@dis animation num_frames_per_second [ skip | noskip ]
where:
animation tells VR-Forces that animation instructions follow.
num_frames_per_second is the rate at which VR-Forces should display the frames.
skip and noskip indicate whether the elapsed time should be used to choose the next frame, or whether at most one frame should be advanced each frame.
You can also specify how many times to loop through an animation and how long to hold the last frame with the following comments:
@dis loopCount count, where count is the number of times to loop through the animation. Default: -1 (loop forever). 0 means do not loop.
@dis lastFrameTime time, where time specifies how long, in seconds, to hold the last frame of the animation.
The loopCount and lastFrameTime comments only work with non-instanced models. You must use them with an animation comment, for example:
@dis animation 2 skip @dis loopCount 3 @dis lastFrameTime 11.5
Table 85-6 through Table 85-11 list the values that you can use for the @dis switch keyword by domain. For any switch keyword, the supported state values (@dis state [value 1],[value 1]...) are listed in the State column. The Bit column lists the appearance bit for setting DIS appearances. (Some bit number are repeated because they are valid only for a particular platform.)
DIS Articulations .
Table 85-2: DIS appearance and states - land domain(Sheet 1 of 3)
Values | Description | State/ Description | Bit |
blackout_brake_lights | State of blackout brake | 0 = Off | 27 |
lights. | 1 = On | ||
blackout_lights | State of blackout lights. | 0 = Off | 26 |
1 = On | |||
brake_lights | State of brake lights. | 0 = Off | 14 |
1 = On | |||
camouflage_type | Type of camouflage. | 0 = Desert | 17-18 |
1 = Winter | |||
2 = Forest | |||
3 = Unused | |||
concealed | Type of concealment. | 0 = Not Concealed | 19 |
1 = In Concealed Position | |||
damage | Damaged appearance of | 0 = None | 3-4 |
an entity. 1 = Slight 2 = Moderate 3 = Destroyed | |||
Table 85-2: DIS appearance and states - land domain(Sheet 2 of 3)
Values Description
fire_power Characteristics of fire- power kill.
flaming State of flames rising from an entity.
frozen_status Frozen status of an entity.
hatch State of the primary hatch.
State/ Description
0 = No
1 = Yes
0 = No
1 = Yes
0 = Not Frozen 1 = Frozen
0 = Not Applicable 1 = Closed
2 = Popped
Bit
2
15
21
9-11
3 = Popped and Person Visible 4 = Open
5 = Open and Person Visible 6 = Custom1
7 = Custom2
head_lights State of headlights. 0 = No 12
1 = Yes
interior_lights State of interior lights. 0 = Off 29
1 = On
launcher State of the platform's primary launcher.
masked_cloaked Describes whether or not
the entity is masked or cloaked.
mobility Characteristics of mobility kill.
0 = Not Raised 16
1 = Raised
0 = No 31
1 = Yes
0 = No 1
1 = Yes
paint_scheme Paint scheme of an entity. 0 = Uniform 0
1 = Camouflage
power_plant_status State of the entity’s
power-plant.
0 = Off 22
1 = On
ramp State of a ramp. 0 = Down 25
1 = Up
smoke State or location of smoke and vapor.
0 = None
1 = Plume
2 = Engine
3 = Engine and Plume
5-6
Table 85-2: DIS appearance and states - land domain(Sheet 3 of 3)
Values | Description | State/ Description | Bit |
spot_lights | Describes whether spot- lights are on or off. | 0 = Off 1 = On | 28 |
tail_lights State of tail lights. 0 = Off 13
tent
tent
State of a tent extension. 0 = Not Extended
1 = Extended
State of a tent extension. 0 = Not Extended
1 = Extended
1 = On
trailing_effects Size of the trailing effect
for the entity.
0 = None
1 = Small
2 = Medium
3 = Large
24
24
7-8
Table 85-3: DIS appearance and states - air domain(Sheet 1 of 2)
Values | Description | State/ Description | Bit |
afterburner | State of an air platform's afterburner. | 0 = Off 1 = On | 16 |
anticollision_lights | State of anti-collision lights. | 0 = Off 1 = On | 14 |
damage | Damaged appearance of an entity. | 0 = None 1 = Slight 2 = Moderate 3 = Destroyed | 3-4 |
flaming | State of flames rising from an entity. | 0 = No 1 = Yes | 15 |
formation_lights | State of formation lights. | 0 = Off 1 = On | 24 |
frozen_status | Frozen status of an entity. | 0 = Not Frozen 1 = Frozen | 21 |
hatch | State of the primary | 0 = Not Applicable | 9-11 |
hatch.
1 = Closed
2 = Popped
3 = Popped and Person Visible 4 = Open
5 = Open and Person Visible 6 = Custom1
7 = Custom2
Table 85-3: DIS appearance and states - air domain(Sheet 2 of 2)
Values | Description | State/ Description | Bit |
interior_lights | State of interior lights. | 0 = Off 1 = On | 29 |
landing_lights | State of landing lights. | 0 = Off 1 = On | 12 |
lights | State of lights. | 0 = Off 1 = On | |
mobility | Characteristics of mobility kill. | 0 = No 1 = Yes | 1 |
navigation_lights | State of navigation lights. | 0 = Off 1 = On | 13 |
paint_scheme | Paint scheme of an entity. | 0 = Uniform 1 = Camouflage | 0 |
power_plant_status | State of the entity’s power-plant. | 0 = Off 1 = On | 22 |
smoke | State or location of smoke and vapor. | 0 = None 1 = Plume 2 = Engine 3 = Engine and Plume | 5-6 |
spot_lights | Describes whether spot- lights are on or off. | 0 = Off 1 = On | 28 |
trailing_effects | Size of the trailing effect | 0 = None | 7-8 |
for the entity.
1 = Small
2 = Medium
3 = Large
Table 85-4: DIS appearance and states - surface domain(Sheet 1 of 2)
Values | Description | State/ Description | Bit |
damage | Damaged appearance of an entity. | 0 = None 1 = Slight 2 = Moderate 3 = Destroyed | 3-4 |
flaming | State of flames rising from an entity. | 0 = No 1 = Yes | 15 |
frozen_status | Frozen status of an | 0 = Not Frozen | 21 |
entity.
1 = Frozen
Table 85-4: DIS appearance and states - surface domain(Sheet 2 of 2) | |||
Values | Description | State/ Description | Bit |
interior_lights | State of interior lights. | 0 = Off 1 = On | 29 |
lights | State of lights. | 0 = Off | |
1 = On | |||
mobility | Characteristics of mobility | 0 = No | 1 |
kill. | 1 = Yes | ||
paint_scheme | Paint scheme of an entity. | 0 = Uniform | 0 |
1 = Camouflage | |||
power_plant_status | State of the entity’s | 0 = Off | 22 |
power-plant. | 1 = On | ||
running_lights | State of running lights. | 0 = Off | 12 |
1 = On | |||
smoke | State or location of | 0 = None | 5-6 |
smoke and vapor. | 1 = Plume | ||
2 = Engine | |||
3 = Engine and Plume | |||
spot_lights | Describes whether spot- | 0 = Off | 28 |
lights are on or off. | 1 = On | ||
trailing_effects | Size of the trailing effect | 0 = None | 7-8 |
for the entity. 1 = Small 2 = Medium 3 = Large | |||
Table 85-5: DIS appearance and states - subsurface domain(Sheet 1 of 2) | |||
Values | Description | State/ Description | Bit |
damage | Damaged appearance of | 0 = None | 3-4 |
an entity. | 1 = Slight | ||
2 = Moderate | |||
3 = Destroyed | |||
flaming | State of flames rising | 0 = No | 15 |
from an entity. | 1 = Yes | ||
frozen_status | Frozen status of an | 0 = Not Frozen | 21 |
entity. | 1 = Frozen | ||
Table 85-5: DIS appearance and states - subsurface domain(Sheet 2 of 2)
Values | Description | State/ Description | Bit |
hatch | State of the primary | 0 = Not Applicable | 9-11 |
hatch. | 1 = Closed | ||
2 = Popped | |||
3 = Popped and Pers | on Visible | ||
4 = Open | |||
5 = Open and Person Visible | |||
6 = Custom1 | |||
7 = Custom2 | |||
mobility | Characteristics of mobility kill. | 0 = No 1 = Yes | 1 |
paint_scheme | Paint scheme of an entity. | 0 = Uniform 1 = Camouflage | 0 |
power_plant_status | State of the entity’s power-plant. | 0 = Off 1 = On | 22 |
running_lights | State of running lights. | 0 = Off 1 = On | 12 |
smoke | State or location of | 0 = None | 5-6 |
smoke and vapor.
1 = Plume
2 = Engine
3 = Engine and Plume
Table 85-6: DIS appearance and states - space domain(Sheet 1 of 2)
Values | Description | State/ Description | Bit |
damage | Damaged appearance of an entity. | 0 = None 1 = Slight 2 = Moderate 3 = Destroyed | 3-4 |
flaming | State of flames rising from an entity. | 0 = No 1 = Yes | 15 |
frozen_status | Frozen status of an entity. | 0 = Not Frozen 1 = Frozen | 21 |
mobility | Characteristics of mobility kill. | 0 = No 1 = Yes | 1 |
paint_scheme | Paint scheme of an entity. | 0 = Uniform 1 = Camouflage | 0 |
Table 85-6: DIS appearance and states - space domain(Sheet 2 of 2)
Values | Description | State/ Description | Bit |
power_plant_status | State of the entity’s power-plant. | 0 = Off 1 = On | 22 |
smoke State or location of smoke and vapor.
0 = None
1 = Plume
2 = Engine
3 = Engine and Plume
5-6
Table 85-7: DIS appearance and states - lifeform domain(Sheet 1 of 2)
Values | Description | State/ Description | Bit | ||||
camouflage_type | Type | of | camouflage. | 0 | = | Desert | 17-18 |
1 | = | Winter | |||||
2 | = | Forest | |||||
3 | = | Unused | |||||
compliance Compliance of lifeform. 0 = Lifeform None
1 = Detained
2 = Surrender 3 = Using Fists
4 = Verbal Abuse 1
5 = Verbal Abuse 2
6 = Verbal Abuse 3
7 = Passive Resistance 1
8 = Passive Resistance 2
9 = Passive Resistance 3
10 = Non-Lethal Weapon 1
11 = Non-Lethal Weapon 2
12 = Non-Lethal Weapon 3
13 = Non-Lethal Weapon 4
14 = Non-Lethal Weapon 5
15 = Non-Lethal Weapon 6
concealed
Type of concealment.
0 = Not Concealed 19
1 = In Concealed Position
concealed
Type of concealment.
0 = Not Concealed 19
1 = In Concealed Position
damage Damaged appearance of an entity.
0 = None
1 = Slight
2 = Moderate
3 = Destroyed
3-4
Table 85-7: DIS appearance and states - lifeform domain(Sheet 2 of 2)
Values | Description | State/ Description | Bit |
flashlight | State of lights. | 0 = Off | |
1 = On | |||
frozen_status | Frozen status of an | 0 = Not Frozen | 21 |
entity. | 1 = Frozen | ||
life_form_state | Lifeform action. | 0 = None | |
1 = Upright Still | |||
2 = Upright Walking | |||
3 = Upright Running | |||
4 = Kneeling | |||
5 = Prone | |||
6 = Crawling | |||
7 = Swimming | |||
8 = Parachuting | |||
9 = Jumping | |||
10 = Sitting | |||
11 = Squatting | |||
12 = Crouching | |||
13 = Wading | |||
14 = Surrender | |||
15 = Detained | |||
paint_scheme | Paint scheme of an entity. | 0 = Uniform | 0 |
1 = Camouflage | |||
weapon_1 | State of primary weapon. | 0 = None | |
1 = Stowed | |||
2 = Deployed | |||
3 = Firing Position | |||
weapon_2 | State of secondary | 0 = None | |
weapon. 1 = Stowed 2 = Deployed 3 = Firing Position | |||
Table 85-8: DIS appearance and states - munition domain
Values | Description | State/ Description | Bit |
damage | Damaged appearance of | 0 = None | 3-4 |
an entity. | 1 = Slight | ||
2 = Moderate | |||
3 = Destroyed | |||
flaming | State of flames rising | 0 = No | 15 |
from an entity. | 1 = Yes | ||
frozen_status | Frozen status of an | 0 = Not Frozen | 21 |
entity. | 1 = Frozen | ||
launch_flash | Describes the presence of | 0 = No | |
a guided munitions launch 1 = Yes flash. | |||
masked_cloaked Describes whether or not
power_plant_status State of the entity’s
power-plant.
power_plant_status State of the entity’s
power-plant.
the entity is masked or cloaked.
0 = No 31
1 = Yes
smoke State or location of smoke and vapor.
0 = Off
1 = On
0 = Off
1 = On
0 = None
1 = Plume
2 = Engine
3 = Engine and Plume
22
22
5-6
trailing_effects
Size of the trailing effect for the entity.
0 = None
1 = Small
2 = Medium
3 = Large
7-8
trailing_effects
Size of the trailing effect for the entity.
0 = None
1 = Small
2 = Medium
3 = Large
7-8
Table 85-9: DIS appearance and states - environmental domain
Values
Description
State/ Description
Bit
Values
Description
State/ Description
Bit
density Density of environmental. 0 = Clear 1 = Hazy
2 = Dense
3 = Very Dense 4 = Opaque
5 = Unused
frozen_status Frozen status of an entity.
0 = Not Frozen 21
1 = Frozen
masked_cloaked
Table 85-10: DIS appearance and states - cultural feature
State/
Bit
Values Description
damage Damaged appearance of an entity.
exterior_lights_on Describes whether the
exterior lights are on or off.
flaming State of flames rising from an entity.
frozen_status Frozen status of an entity.
Description
0 = None
1 = Slight
2 = Moderate
3 = Destroyed
0 = Off
1 = On
0 = No
1 = Yes
0 = Not Frozen 1 = Frozen
3-4
28
15
21
interior_lights State of interior lights. 0 = Off 29
1 = On
internal_heat_on Describes whether the
internal heat is on or off.
masked_cloaked Describes whether or not
the entity is masked or cloaked.
0 = Off 22
1 = On
0 = No 31
1 = Yes
smoke
State or location of smoke and vapor.
0 = None 5-6
1 = Plume
2 = Engine
3 = Engine and Plume
smoke
State or location of smoke and vapor.
0 = None 5-6
1 = Plume
2 = Engine
3 = Engine and Plume
Table 85-11: DIS appearance and states - sensor domain(Sheet 1 of 2)
Values | Description | State/ Description | Bit |
antenna_raised | Describes whether the antenna is raised or not | 0 = Lowered 1 = Raised | 16 |
blackout_lights | State of blackout lights. | 0 = Off 1 = On | 26 |
concealed | Type of concealment. | 0 = Not Concealed 19 1 = In Concealed Position | |
camouflage_type | Type of camouflage. | 0 = Desert 1 = Winter 2 = Forest 3 = Unused | 17-18 |
Table 85-11: DIS appearance and states - sensor domain(Sheet 2 of 2)
Values | Description | State/ Description | Bit |
damage | Damaged appearance of | 0 = None | 3-4 |
an entity. | 1 = Slight | ||
2 = Moderate | |||
3 = Destroyed | |||
flaming | State of flames rising | 0 = No | 15 |
from an entity. | 1 = Yes | ||
frozen_status | Frozen status of an | 0 = Not Frozen | 21 |
entity. | 1 = Frozen | ||
interior_lights | State of interior lights. | 0 = Off | 29 |
1 = On | |||
lights | State of lights. | 0 = Off | |
1 = On | |||
mission_killed | Ability to carry out | 0 = No | 2 |
mission. | 1 = Yes | ||
mobility | Characteristics of mobility | 0 = No | 1 |
kill. | 1 = Yes | ||
paint_scheme | Paint scheme of an entity. | 0 = Uniform | 0 |
1 = Camouflage | |||
power_plant_status | State of the entity’s | 0 = Off | 22 |
power-plant. | 1 = On | ||
smoke | State or location of | 0 = None | 5-6 |
smoke and vapor. | 1 = Plume | ||
2 = Engine | |||
3 = Engine and Plume | |||
tent | State of a tent extension. | 0 = Not Extended | 24 |
1 = Extended | |||
trailing_effects | Size of the trailing effect | 0 = None | 7-8 |
for the entity. 1 = Small 2 = Medium 3 = Large | |||
Table 85-12 lists the supported values for the @dis articulated_part keyword. String values are part of the WRM specification, but are not currently supported.
Table 85-12: DIS Articulations(Sheet 1 of 5)
Value | String | Description |
3296 | bridge_launcher | Position of the bridge launcher. |
3328 | bridge_section_1 | Position of bridge section 1. |
3360 | bridge_section_2 | Position of bridge section 2. |
3392 | bridge_section_3 | Position of bridge section 3. |
7616 | fuselage_fold | Fold on plane’s body. |
1184 | helicopter_main_rotor | Describes main rotor rotation. |
1216 | helicopter_tail_rotor | Describes tail rotor rotation. |
3072 | landing_gear | Landing gear on a plane. |
3520 | launcher_arm_primary | Position of the primary launcher arm. |
1120 | left_aileron | Position of the left aileron. |
1056 | left_flap | Position of the left flap. |
3168 | left_weapon_bay_door | Left door to weapon bay. |
3552 | other | Position of other articulated parts. |
3424 | primary_blade_1 | Position of the primary blade 1. |
3456 | primary_blade_2 | Position of the primary blade 2. |
3488 | primary_boom | Position of the primary boom. |
5056 | primary_defense_systems_1 | Position of the primary defense systems 1. |
5088 | primary_defense_systems_2 | Position of the primary defense systems 2. |
5120 | primary_defense_systems_3 | Position of the primary defense systems 3. |
5152 | primary_defense_systems_4 | Position of the primary defense systems 4. |
5184 | primary_defense_systems_5 | Position of the primary defense systems 5. |
5216 | primary_defense_systems_6 | Position of the primary defense systems 6. |
5248 | primary_defense_systems_7 | Position of the primary defense systems 7. |
5280 | primary_defense_systems_8 | Position of the primary defense systems 8. |
5312 | primary_defense_systems_9 | Position of the primary defense systems 9. |
5344 | primary_defense_systems_10 | Position of the primary defense systems 10. |
4416 | primary_gun_number_1 | Position of the primary gun number 1. |
4448 | primary_gun_number_2 | Position of the primary gun number 2. |
4480 | primary_gun_number_3 | Position of the primary gun number 3. |
4512 | primary_gun_number_4 | Position of the primary gun number 4. |
4544 | primary_gun_number_5 | Position of the primary gun number 5. |
4576 | primary_gun_number_6 | Position of the primary gun number 6. |
4608 | primary_gun_number_7 | Position of the primary gun number 7. |
4640 | primary_gun_number_8 | Position of the primary gun number 8. |
4672 | primary_gun_number_9 | Position of the primary gun number 9. |
4704 | primary_gun_number_10 | Position of the primary gun number 10. |
4736 | primary_launcher_1 | Position of primary launcher 1. |
4768 | primary_launcher_2 | Position of primary launcher 2. |
4800 | primary_launcher_3 | Position of primary launcher 3. |
4832 | primary_launcher_4 | Position of primary launcher 4. |
4864 | primary_launcher_5 | Position of primary launcher 5. |
4896 | primary_launcher_6 | Position of primary launcher 6. |
4928 | primary_launcher_7 | Position of primary launcher 7. |
4960 | primary_launcher_8 | Position of primary launcher 8. |
4992 | primary_launcher_9 | Position of primary launcher 9. |
5024 | primary_launcher_10 | Position of primary launcher 10. |
5376 | primary_radar_1 | Position of the primary radar 1. |
5408 | primary_radar_2 | Position of the primary radar 2. |
5440 | primary_radar_3 | Position of the primary radar 3. |
5472 | primary_radar_4 | Position of the primary radar 4. |
5504 | primary_radar_5 | Position of the primary radar 5. |
5536 | primary_radar_6 | Position of the primary radar 6. |
5568 | primary_radar_7 | Position of the primary radar 7. |
5600 | primary_radar_8 | Position of the primary radar 8. |
5632 | primary_radar_9 | Position of the primary radar 9. |
5664 | primary_radar_10 | Position of the primary radar 10. |
4096 | primary_turret_number_1 | Position of the primary turret number 1. |
4128 | primary_turret_number_2 | Position of the primary turret number 2. |
4160 | primary_turret_number_3 | Position of the primary turret number 3. |
4192 | primary_turret_number_4 | Position of the primary turret number 4. |
4224 | primary_turret_number_5 | Position of the primary turret number 5. |
4256 | primary_turret_number_6 | Position of the primary turret number 6. |
4288 | primary_turret_number_7 | Position of the primary turret number 7. |
4320 | primary_turret_number_8 | Position | of | the | primary | turret | number | 8. |
4352 | primary_turret_number_9 | Position of the primary turret number 9. | ||||||
4384 | primary_turret_number_10 | Position of the primary turret number 10. | ||||||
1152 | right_aileron | Position of the right aileron. | ||||||
1088 | right_flap | Position of the right flap. | ||||||
3200 | right_weapon_bay_doors | Right door to the weapon bay. | ||||||
7584 | rotor_fold | Fold on helicopters rotors. | ||||||
1024 | rudder | Position of the rudder. | ||||||
6656 | secondary_defense_sys- tems_1 | Position of the secondary defense systems 1. | ||||||
6688 | secondary_defense_sys- tems_2 | Position of the secondary defense systems 2. | ||||||
6720 | secondary_defense_sys- tems_3 | Position of the secondary defense systems 3. | ||||||
6752 | secondary_defense_sys- tems_4 | Position of the secondary defense systems 4. | ||||||
6784 | secondary_defense_sys- tems_5 | Position of the secondary defense systems 5. | ||||||
6816 | secondary_defense_sys- tems_6 | Position of the secondary defense systems 6. | ||||||
6848 | secondary_defense_sys- tems_7 | Position of the secondary defense systems 7. | ||||||
6880 | secondary_defense_sys- tems_8 | Position of the secondary defense systems 8. | ||||||
6912 | secondary_defense_sys- tems_9 | Position of the secondary defense systems 9. | ||||||
6944 | secondary_defense_sys- tems_10 | Position of the secondary defense systems 10. | ||||||
6016 | secondary_gun_number_1 | Position of the secondary gun number 1. | ||||||
6048 | secondary_gun_number_2 | Position of the secondary gun number 2. | ||||||
6080 | secondary_gun_number_3 | Position of the secondary gun number 3. | ||||||
6112 | secondary_gun_number_4 | Position of the secondary gun number 4. | ||||||
6144 | secondary_gun_number_5 | Position of the secondary gun number 5. | ||||||
6176 | secondary_gun_number_6 | Position of the secondary gun number 6. | ||||||
6208 | secondary_gun_number_7 | Position of the secondary gun number 7. | ||||||
6240 | secondary_gun_number_8 | Position of the secondary gun number 8. | ||||||
Table 85-12: DIS Articulations(Sheet 4 of 5)
Value | String | Description |
6272 | secondary_gun_number_9 | Position of the secondary gun number 9. |
6304 | secondary_gun_number_10 | Position of the secondary gun number 10. |
6336 | secondary_launcher_1 | Position of the secondary launcher 1. |
6400 | secondary_launcher_3 | Position of the secondary launcher 3. |
6432 | secondary_launcher_4 | Position of the secondary launcher 4. |
6464 | secondary_launcher_5 | Position of the secondary launcher 5. |
6496 | secondary_launcher_6 | Position of the secondary launcher 6. |
6528 | secondary_launcher_7 | Position of the secondary launcher 7. |
6560 | secondary_launcher_8 | Position of the secondary launcher 8. |
6592 | secondary_launcher_9 | Position of the secondary launcher 9. |
6624 | secondary_launcher_10 | Position of the secondary launcher 10. |
6368 | secondary_launcher_2 | Position of the secondary launcher 2. |
6976 | secondary_radar_1 | Position of secondary radar 1. |
7008 | secondary_radar_2 | Position of secondary radar 2. |
7040 | secondary_radar_3 | Position of secondary radar 3. |
7072 | secondary_radar_4 | Position of secondary radar 4. |
7104 | secondary_radar_5 | Position of secondary radar 5. |
7136 | secondary_radar_6 | Position of secondary radar 6. |
7168 | secondary_radar_7 | Position of secondary radar 7. |
7200 | secondary_radar_8 | Position of secondary radar 8. |
7232 | secondary_radar_9 | Position of secondary radar 9. |
7264 | secondary_radar_10 | Position of secondary radar 10. |
5696 | secondary_turret_number_1 | Position of the secondary turret number 1. |
5728 | secondary_turret_number_2 | Position of the secondary turret number 2. |
5760 | secondary_turret_number_3 | Position of the secondary turret number 3. |
5792 | secondary_turret_number_4 | Position of the secondary turret number 4. |
5824 | secondary_turret_number_5 | Position of the secondary turret number 5. |
5856 | secondary_turret_number_6 | Position of the secondary turret number 6. |
5888 | secondary_turret_number_7 | Position of the secondary turret number 7. |
5920 | secondary_turret_number_8 | Position of the secondary turret number 8. |
5952 | secondary_turret_number_9 | Position of the secondary turret number 9. |
5984 | secondary_turret_number_10 | Position of the secondary turret number 10. |
3104 | tail_hook | Tail hook on a plane for aircraft carrier land- ings. |
7584 | wing_fold | Fold on plane’s wings. |
The appendixes contain supplementary information.
VR-Forces Users Guide
Section XIV - Appendixes
XIV-1
Section XIV - Appendixes
XIV-2 VT MAK
This chapter describes the syntax of VR-Forces MTL files.
Introduction ................................................................................................. A-2 MÄK Technologies Lisp (MTL) Files ........................................................... A-3
Using Environment Variables in an MTL File........................................ A-3
Specifying Lists of Lists .......................................................................... A-4
Using Conditional Statements................................................................ A-4
MTL Syntax — Introduction
Developers may need to create and edit configuration files using the VR- Forces Front-End API. Please see VR-Forces Front-End Developers Guide and the class documentation for details.
The back-end configuration files mostly use the MÄK Technologies LISP (MTL) syntax. The major back-end configuration file is vrfSim.mtl. It is described in Appendix A, MTL Syntax. Other files are described throughout this manual in the appropriate section.
MTL Syntax — MÄK Technologies Lisp (MTL) Files
Many of the configuration files for MAK products are ASCII text files that use MÄK Technologies LISP (MTL) to encode configuration information. MTL files have the extension .mtl. You can edit them in any text editor. Be sure that your text editor uses the proper end-of-line characters for your platform.
Most parameter entries take the format:
(setq parameter_name value)
For example:
(setq EnableWireFrame 1)
Or:
(setqb parameter_name value)
The setqb syntax indicates a bound variable.
To comment out a line, precede the text with two semi-colons (;;). You can also add a comment at the end of a line by preceding it with two semi-colons.
In most cases, the parameter names are known to the MAK application and the MTL commands simply assign values to them. However, you can use the setq command to create arbitrary symbolic names or aliases that are then used in later commands. For example, in the following two commands, the symbolic name VaporTrail is assigned to an OpenFlight file. Then the symbolic name is used in the trail-map command.
The name VaporTrail has no intrinsic meaning. It is given meaning by the setq
command, which allows it to be used later in the trail-map command.
(setq VaporTrail (list "./../data/models/makTrails/Vapor- Trail" "VaporTrail.flt" 6.0 1.5 1.5 4.0 1.5 0.5))
(trail-map (list 1 2 -1 0 -1 -1 -1)(list VaporTrail 0.0 0.0
0.0))
In addition to the setq command, a commonly used command is the load command. This command instructs the application to load the file specified, for example:
(load mtl-path "params.mtl")
If you want to use an environment variable in an MTL file, use the following syntax:
(setqb parameter_name (getenv (quote env_var)))
For example:
(setqb disDestAddr (getenv (quote DEST_ADDR)))
MTL Syntax — MÄK Technologies Lisp (MTL) Files
The example of setting a symbolic name in a previous section uses a list. You can also specify a list of lists, for example:
(trail-map (list 1 2 -1 -1 -1 -1 -1)
(list vaporTrail -8.0 -3.0 0.0)
(list vaporTrail -8.0 3.0 0.0)
)
A parameter entry can also have multiple individual lists:
(trail-map (list 1 2 -1 0 -1 -1 -1)(list VaporTrail 0.0 0.0
0.0))
MTL commands can be conditional. Conditional statements are used frequently when parameters are different for DIS and HLA. A simple conditional statement has the format:
(if (condition) (statement_to_evaluate))
If you have more than one statement to evaluate, use a sequence block:
;; HLA specific parameters (if (equal HLA 1)
(sequence
(setqb fomMapperLib "") (setqb fomMapperInitData "") (setqb rprFomVersion 1.0)
(setqb pathToSublistFile "sublist.mtl") (setqb ignoreAdvisories 0)
(setqb fedLookahead 1.0)
)
)
B. The vrfSim.mtl Configu- ration File
This chapter describes the vrfSim.mtl file.
The vrfSim.mtl Configuration File ............................................................... B-2
The file ./appData/settings/vrfSim/vrfSim.mtl configures back-ends. Table B-1 describes the parameters in vrfSim.mtl. The Description column includes the command-line argument equivalent for parameters that have them.
Table B-1: vrfSim.mtl parameters (Sheet 1 of 7)
additionalSystemScriptsDirec- tory
aggregateSpatialModelTickPeri- odUsesRealTime
aggregateSpatialModelTickPe- riod
aggregateSpatialModelTickVari- ance
aggregateSpatialModelTickAs- FastAsPossibleWhilePaused
Directories other than the default script directory where VR-Forces should look for system scripts.
Configure aggregate spatial model tick rates. Default is to run the aggregate spatial model every frame. Tick period is given in seconds, with the special value of -1 indicating tick every frame.
appNumber Specifies the application number.
Default: 3001. Command line: -a | -p
assertOnBlockingTerrainCalls When set to true (1), causes blocking terrain calls to assert
in debug mode if the simulation is running. Blocking terrain calls can cause long ticks in a running simulation which can have very negative effects on the models. This parameter can help developers find places in the code that are making the offending calls. Note that calling the blocking form of any terrain intersection function causes an assertion; it is not necessary for the call to actually block and even non- paging implementations will assert. This is to make it easier to find potential problems regardless of the particular terrain or location being used. Default: 0. For more infor- mation, please see API documentation.
batchScenarioFileName Specifies a batch file to run. Command line: -B
cgfDispatcherReceivePort Specifies the port to be used by the
DtCgfDispatcher’s file transporter to receive order of battle and plan files from the DtVrfRemoteController.
countryCodesMappingFile The file VR-Forces uses to import country codes to map to
daemon Runs vrfSim as a daemon process (Linux only.) vrfSim does not try to read characters from a console, and forks a back- ground process on startup. It exits cleanly on receipt of the SIGTERM, SIGQUIT, SIGINT signals. Default: Off.
Command line: --daemon
datumShiftX datumShiftY datumShiftZ
These parameters, along with the spheroidSemiMajor and spher- oidSemiMinor parameters, let you change the reference ellip- soid used for geocentric to geodetic conversions. For more information, please see Choosing a Reference Ellipsoid in VR-Link Developers Guide. These parameters are used only if VRF_useCustomMapDatum is set to 1.
defaultParameterDatabasePath Specifies the location to search for the object parameter
database if the full path is not specified in a scenario file.
defaultTerrainDatabasePath Specifies the location to search for the terrain database if
the full path is not specified in a scenario file.
diGuyAnimationsFile Specifies the DI-Guy animations file to load if useDIGuy is 1.
disableParallelTick If enabled (1), VR-Forces ticks thread safe components in
parallel. If disabled (0), all components are ticked serially in the main thread.
doNotUseConsole Disables (1) or enables (0) writing of output to the console.
Default: 0.
enableDebugDrawer Enables (1) or disables (0) the simulation terrain debug
enableLogFileTimestamps If enabled, puts timestamps in front of each line in for all
log files.
enableNavigationLabDebugging Enables debugging using the Navigation Lab application. A
connection is made on an available port, starting with 4888, to enable Navigation Lab to connect to the simula- tion engine.
entVrfDataTimeThreshold Specifies how often, in seconds, VR-Forces environmental
forceParameterDbReload If set to 1 (default), forces the back-end to reload the
object parameter database (OPD) each time a scenario is loaded. If set to 0, if a scenario is started that uses the same SMS as the previous one (for example, in a rewind), the SMS is not reloaded.
frameRateStatisticsLogFile Specifies a log file for frame rate statistics.
gamewareMemorySize Set the working memory size limit used internally by Game-
Ware when calculating paths. Size is in MB. Increasing this limit can allow for path plans on larger navigation areas by more entities simultaneously. Note: Multiple working memory blocks are allocated with this limit, so this is not an overall limit for Gameware.
loadPluginIfVersionMismatch Specifies whether (1) or not (0) to load a plug-in if there is
a mismatch between how the plug-in was built and how VR-Forces was built. Mismatches can be build type (release versus debug), operating system, or protocol (DIS, HLA 1.3, HLA 1516, HLA Evolved.)
Allowing a plug-in to load if there is a mismatch can cause VR-Forces to be unstable.
logFrameRateStatistics Enables (1) or disables (0) logging of frame rate statistics
maxDrainInputTime Sets the maximum time to wait in drainInput() before
returning. For the MAK RTI, the default value drains the entire input stream before returning. For the Pitch RTI, the default value reads a single input from the input stream, so set to a value other than -1 to process more information. Use with DIS or HLA.
msdlSIDCMappingFile The file VR-Forces uses to map between SIDC codes and
object type enumerations when it imports MSDL files.
notifyLevel Sets the notification level (0-4) for information and warning messages. Default: 2. Command line: -n
objectConsoleNotifyLevel Specifies the notification level (0-4) for messages sent to the object console. Default: 1.
pluginsDirectory Specifies the directory in which configuration (MTL) files
for plug-ins are located. The directory must end with a slash, for example, ./plugins/
publishZeroVelocityWhenPaused When set to 1, the default, VR-Forces sets simulation
object velocities to 0 when it is paused so that simulation objects do not continue to dead reckon. To publish the current velocity, set to 0.
rejectMismatchedScenarioMes- sages
reuseEntityIdentifiersOnScenari- oLoad
If true (the default) reject mismatched scenario run messages based on unique scenario run id.
If true, reuse object identifiers that might be part of the scenario. If the object identifier saved in the order of battle does not currently match the site/app of the back-end loading that object, then the user will be warned and the object will be assigned a new entity identifier that is compliant with that site/app. This will not apply to simula- tion object groups or scenario import. They will always get new entity identifiers.
scenarioFileName Specifies the scenario file to load. Command line: -L
sendBackendLogToNetwork Enables (1) or disables (0) sending simulation engine log
sessionId Specifies the session ID. Command line: -i
setDeadReckoningAlgorithmTo- StaticOnPause
When the simulation is paused, set the dead reckoning algorithm for aggregates and entities to static. If enabled and publishZeroVelocityWhenPaused is disabled, the objects in a VR-Forces run simulation show current values for velocity, speed, acceleration, and so on.
setMainThreadToHighPriority If set to 1, sets the main thread to THREAD_PRIORITY_-
simMgmtPduProcessLevel Specifies how simulation management PDUs are
processed:
– Processes PDUs sent to a specific back-end. Wildcards are ignored.
– Processes only wildcarded PDUs. Ignores those sent to specific back-ends.
simulationModelSet Specifies the default simulation model set or sets. If speci-
fying multiple SMSs, separate them by a semi-colon.
siteId Specifies the site ID. 0 = use internal default.
Command line: -s | -t
spheroidSemiMajor spheroidSemiMinor
These parameters, along with the datumShift parameters, let you change the reference ellipsoid used for geocentric to geodetic conversions. For more information, please see Choosing a Reference Ellipsoid in VR-Link Developers Guide. These parameters are used only if VRF_useCustomMap- Datum is set to 1.
startInRunMode Specifies that the simulation start in run mode (1), rather than pause mode (0). Default: 0.
startMinimized If true (1), the back-end minimizes at startup.
statusUpdateHeartbeat Specifies how often, in seconds, the back-end status heart-
targetFrameRate Specifies the mean frame rate above which the back-end
will sleep, yielding CPU time to other processes. This option applies only to variable frame mode. For more infor- mation, please see “Tuning the Target Frame Rate,” on page 6-17. Default: 22.
taskVisualizationPublication- Mode
Specifies whether or not to publish task visualizations and how to publish them, as follows:
0 = Never publish task visualizations.
1 = Standard mode. The VR-Forces GUI will request task visualizations only for objects for which they are enabled.
2 = Always publish task visualizations, regardless of whether they are being displayed in the GUI. Can be useful for logging purposes.
terrainDatabase Specifies the terrain database to load. This parameter is
overridden by the scenario file if one is specified in scenario-
FileName. Command line: -T
useCustomMapDatum Allows modification of the reference ellipsoid used for
geocentric to geodetic conversion. If you enable this parameter, there are several sub-parameters to configure. For details, please see the comments in the file.
useDrawControlForTaskVisual- izations
If true, publish task visualizations as VR-Vantage draw control objects instead of their standard publication method. This allows task visualizations to be displayed in any VR-Vantage based application; however the VR-Forces GUI will no longer be able to filter task visualizations by entity.
useDIGuy Specifies whether (1) or not (0) to use DI-Guy characters.
HLA Parameters
For details, please see “Command-line Options for HLA Federations,” on page 5-17
HLA Parameters
For details, please see “Command-line Options for HLA Federations,” on page 5-17
destroyFedExec Specifies whether (1) or not (0) the DtExerciseConn
destructor should try to destroy the federation execution. Default: 1.
execName The federation execution name. Command line: -x
federateName The federate name. Command line: -N
federateType Lets you specify the federate type for HLA Evolved.
fedFileName Specifies the FED file name. Command line: -F
fomMapperLib A FOM Mapper library. Command line: -f
fomMapperInitData An initialization string.
Command line: --fomMapperInitData
hostAddressString Specifies the host address. This is usually the same as the
localSettingsDesignator Specifies the local settings designator for HLA Evolved.
mimModule Specifies a MIM (MOM and Initialization) Module for HLA Evolved.
minDrainInputTime The minimum time to stay in drainInput() before returning.
rprFomVersion The RPR FOM version. (0.5, 0.8, 1.0, 2.0)
Command line: --rprFomVersion
runInTimeManagementMode Enables (1) or disables (0) use of time management.
sendFedTime Enables (1) or disables (0) sending and receipt of interac-
tions in time stamp order. Default: 0.
useAbsoluteTimeStamps If set to 1, use absolute time stamps. If set to 0, use rela-
useAdvisories Enables (1) or disables (0) HLA advisory messages.
DIS Parameters
Please see “Command-line Options for DIS Exercises,” on page 5-20.
DIS Parameters
Please see “Command-line Options for DIS Exercises,” on page 5-20.
additionalDestinationAddresses Specifies additional destination addresses to send to.
Accepts multiple IP addresses separated by semi-colons (;).
addMulticastAddr The multicast address. Command line: -S
appIdRange Specifies the application ID range to use to identify simula- tion objects generated by VR-Forces.
defaultHeartbeatThreshold Specifies the DIS heartbeat threshold, in seconds. A heart-
beat is sent when the threshold is reached, even if no data has changed.
defaultObjectTimeout Specifies the DIS object timeout threshold, in seconds. If
destAddrString Destination address for point-to-point communications
deviceAddress Specifies the address of the network card to use for UDP
disPort The port number. Command line: -P
exerciseId The exercise ID. Command line: -x
heartbeatVariance When a simulation object is created, a random value
between -heartbeatVariance and +heartbeatVariance is added to the heartbeat. This spreads heartbeats over time instead of them all being at the same time.
hostAddressString Specifies the host address. This is usually the same as the
maxDrainInputReads The maximum number of reads to make in drain input
mcastTtl Specifies the multicast time to live.
Command line: --mcastTtl
recvBufferSize Specifies the receive buffer size, as a positive value. A
value of -1 means use the system default.
Command line: --recvBufferSize
sendBufferSize Specifies the send buffer size, as a positive value. A value
of -1 means use the system default.
Command line: --sendBufferSize
subnetMask When the destination address is not specified (“0.0.0.0”), the subnet mask is used in conjunction with the network interface address to determine the destination broadcast address. If neither is specified (subnet mask is blank), the network interface's default broadcast address is used.
suppressSelfReflect Prevent VR-Forces from reflecting DIS PDUs.
useAbsoluteTimeStamps If set to 1, use absolute time stamps. If set to 0, use rela-
useAsyncIO Enables (1) or disables (0) use of asynchronous I/O, which can help reduce dropped packets under heavy network load. Default: 0. Command line: -I
useIpv6 Use the IPV6 protocol.
This appendix describes the high-level parameters in the object parameter database. The OPD Editor has context-sensitive help for most parameters and also describes them in the online help system. It also has reference material for local and remote subcomponents and object type enumerations.
The Structure of a Simulation Object Parameter.......................................... C-2 The Parameter Type Hierarchy.................................................................... C-3
Vrf Base Object Parameters ................................................................... C-3
Vrf Object Parameters........................................................................... C-7
Moving Object Parameters.................................................................... C-8
Parameter Types for Entity Platforms.................................................... C-8
Simulation Object Parameters...................................................................... C-8
Object Type Enumerations.......................................................................... C-9
Object Super-type ................................................................................. C-9
AggregateKind....................................................................................... C-9
ObjectKind ......................................................................................... C-10
Unit Category ..................................................................................... C-10
Unit Specific ....................................................................................... C-11
Point Object Category......................................................................... C-12
Linear Object Category ....................................................................... C-12
Areal Object Category ......................................................................... C-12
Interaction........................................................................................... C-12
Object Parameters — The Structure of a Simulation Object Parameter
Many of the files in the object parameter database uses MAK Technologies LISP (MTL). (For details about MTL, please see “MÄK Technologies Lisp (MTL) Files,” on page A-3.) A parameter block has the form:
(block_name
( parameter_name value)
...
(parameter_name
(sub-parameter value)
)
and so on
)
Entries have the following requirements:
The block_name can be anything that you like. It must not start with a number.
The parameter_name must be exactly as documented (except that in some cases, a parameter may contain an arbitrary length list of sub-parameters, for which the parameter names are not used – these will be noted). Parameter names must not contain spaces, and must not start with a digit (or a dash followed by a digit, for example, -1).
The first parameter in any parameter block must be parameter-type.
You can include comments in the file. A comment begins with a semicolon(;) and continues to the end of the line.
All numerical parameters use standard MKS values: meters, kilograms, seconds, radians, liters, and so on.
Real constants must begin with a digit and contain a decimal point. For example,
0.5 and 0. are acceptable, but .5 and 0 are not.
i .entity files use XML format, not MTL.
Figure 69-4, in “Parameter Types,” on page 69-8, illustrates the hierarchy of parameter types. In this section, we describe the parameters associated with each parameter-type.
All object parameters inherit from the parameter type vrf-base-object-param. The parame- ters associated with vrf-base-object-param are potentially applicable to any type of object (ground, rotary-wing, control object, and so on). Please see the General Parame- ters topic in the OPD Editor online help for parameter descriptions. In addition to parameters, each object has an object type and parameter type, as described in Table
C-1.
Table C-1: Object and parameter type
object-type (Required) 8-digit object type. Not actually a parameter. Specifies the key used to look up the entry. For more information, please see “Object Types,” on page 69-4.
parameter-type (Required) One of the following (string):
"vrf-base-object-param"
"vrf-object-param"
"moving-object-param"
"fixed-wing-entity-param"
"ground-vehicle-param"
"rotary-wing-entity-param"
"missile-param"
"surface-entity-param"
"subsurface-entity-param"
“human-param”
“aggregate-object-param”
“cultural-feature-param”
“bomb-param”
“global-environment-param”
“circle-object-param”
“point-object-param”
“scripted-movement-object-param”
“tactical-smoke-param”.
The value must be in quotation marks.
The local-objects parameter specifies the types of subcomponents to create for locally simulated objects. You can omit optional items, or set them with an empty string “”. Table C-2 lists the subcomponent parameters and their possible values.
Table C-2: Local-objects subcomponent parameters (Sheet 1 of 2)
Subcomponent Description parameter
Subcomponent Description parameter
state-repository (Required) Maintains the state information for the object. An object that has components (sensors, controllers, and actuators) for simulation sets and retrieves information in the repository.
Some simulation components expect a specific kind of state repository. In general, you will want to specify the state reposi- tory type that most closely matches the kind of simulation object you expect to simulate. May be one of the following types:
"vrf-object-base-state-repository": Used for the base object in the object parameter database.
"vrf-object-state-repository": Derived from vrf-object-base- state-repository, it adds the concepts of resources, sector of responsibility, engagement rules, and targeting. Because there are more simulation object-specific state repository types that are derived from this type, this kind of repository is not typi- cally specified.
“vrf-overlay-object-state-repository”: For tactical graphics.
"vrf-moving-object-state-repository": For any object that you expect to simulate movement. Units in entity-level scenarios have this kind of state repository. The more simulation object- specific repository types that follow inherit this kind of state repository, so choose one of those when simulating a specific type of individual entity.
"ground-entity-state-repository": For ground vehicles, such as tanks, trucks, dismounted infantry.
"rotary-wing-entity-state-repository": For rotary-wing aircraft.
"fixed-wing-entity-state-repository": For fixed-wing aircraft.
"missile-entity-state-repository": For missile and rocket enti- ties.
"surface-entity-state-repository": For surface entities.
"subsurface-entity-state-repository": For subsurface entities.
“human-state-repository”: For lifeform entities.
“vrf-aggregate-state-repository”: For units.
“cultural-feature-state-repository”: For cultural features that are created as entities.
Table C-2: Local-objects subcomponent parameters (Sheet 2 of 2)
Subcomponent Description parameter
Subcomponent Description parameter
network-interface (Optional) The network interface handles the publication of the object over the network. It acts as an interface between a simula- tion object’s state repository and its network (VR-Link) represen- tation. Choose one that most closely matches the kind of simulation object you are simulating. May be one of the following types:
"aggregate-local-entity-net-interface": For units.
"pseudo-aggregate-local-entity-net-interface": For units that have subordinate simulation objects that are separately simu- lated.
"individual-local-entity-net-interface": For individual platform entities, such as tanks, aircraft, dismounted infantry.
net-interface-min-tick- period
net-interface-min-tick- period-variance
(Optional) Specifies the shortest period of time, in seconds, that can elapse between ticks of a simulation object’s network inter- face.
(Optional) Specifies an amount within which the net-interface-min-tick- period can vary. Defined as:
plus or minus rand(net-interface-min-tick-period/2)
component-manager (Optional) A component manager contains the lists of sensor, controller, and actuator components used to simulate the behavior of a given object (typically simulation objects). Expected value: "component-manager".
plan-manager (Optional) The simulation object plan manager. If you want a simulation object to be able to execute a plan, it must have a plan manager.
task-manager (Optional) If a component manager is specified for an object, then you must specify a task manager. The task manager works in conjunction with the component manager to manage the processing and message handling associated with execution of a task. Expected value for individual entities or units: "local-task- manager".
The remote-objects parameter specifies the types of sub-components to create for remote objects. Remote objects are those objects simulated by other applications on the network (including other VR-Forces applications). You can omit optional items, or set them with an empty string "". Table C-3 lists the subcomponent parameters and their possible values.
Table C-3: Remote object subcomponent parameters (Sheet 1 of 2)
Subcomponent
Subcomponent
state-repository (Required) Maintains the state information for the object. Unlike the local-object entry, it is not as important to specify the closest match based on type. For entities, the "vrf-moving-object-state- repository" is sufficient. A more specific state repository may be specified. However, some of the simulation object-specific data may not be set. May be one of the following types:
"vrf-object-state-repository": Derived from vrf-object-base- state-repository, it adds the concepts of resources, sector of responsibility, engagement rules, and targeting. Because there are more simulation object-specific state repository types that are derived from this type, this kind of repository is not typi- cally specified.
"vrf-overlay-object-state-repository": For tactical graphics.
"vrf-moving-object-state-repository": For any object that you expect to simulate movement, including individuals and units.
"ground-entity-state-repository": For ground vehicles, such as tanks, trucks, dismounted infantry.
"rotary-wing-entity-state-repository": For rotary-wing aircraft.
"fixed-wing-entity-state-repository": For fixed-wing aircraft.
"missile-entity-state-repository": For missile and rocket enti- ties.
“human-state-repository”: For lifeform entities.
“vrf-aggregate-state-repository”: For units.
“cultural-feature-state-repository”: For cultural features that are created as entities.
"surface-entity-state-repository": For surface entities.
"subsurface-entity-state-repository": For subsurface entities.
Table C-3: Remote object subcomponent parameters (Sheet 2 of 2)
Subcomponent
Subcomponent
network-interface (Optional) The network interface is the interface between the remote network (VR-Link) representation of the object and its state repository. It acts as an interface between a simulation object’s state repository and its network (VR-Link) representa- tion. Choose one that most closely matches the kind of simula- tion object you are simulating. May be one of the following types:
"vrf-aggregate-remote-entity-net-interface": For remote units.
"vrf-individual-remote-entity-net-interface": For individual platform entities, such as tanks, aircraft, dismounted infantry.
net-interface-min-tick- period
net-interface-min-tick- period-variance
(Optional) Specifies the shortest period of time, in seconds, that can elapse between ticks of a simulation object’s network inter- face.
(Optional) Specifies an amount within which the net-interface-min-tick- period can vary. Defined as:
plus or minus rand(net-interface-min-tick-period/2)
plan-manager Do not specify a plan manager for remote objects. (Give it the value "" (empty string). If you specify a plan manager, it is ignored.)
component-manager Do not specify a component manager for remote objects. (Give it the value "" (empty string). If you specify a component manager, it is ignored.)
task-manager (Optional) Do not specify a task manager for remote objects. (Give it the value "" (empty string). If you specify a task manager, it is ignored.)
The parameter type vrf-object-param inherits from vrf-base-object-param and is the parent of the moving object parameter type. Vrf object parameters include resources, engage- ment rules, and target acquisition time. The vrf-object-param parameter type represents an intermediate class in the parameter hierarchy. It is not usually used to represent objects in VR-Forces. You will probably want to instantiate a derived type, (for simula- tion objects) or you will want to specify vrf base object parameters (for case of control objects.)
Control objects have the parameter type vrf-base-object-param.
Object Parameters — Simulation Object Parameters
Moving objects have the parameter type moving-object-param. Moving objects inherit parameters from vrf objects and vrf base objects. The moving-object-param parameter type is used for objects that are capable of movement, such as simulation objects. Parameters include support points, maximum speed, maximum reverse speed, turning radius, maximum slope, ordered speed, maximum acceleration, maximum deceleration, and fuel efficiency. Units are moving objects and have this parameter type. All of the plat- form-specific parameter types derive from this one.
Table C-4 lists the parameter types used by each entity type.
Table C-4: Parameter types for simulation objects
Platform | Inherits from | |
Ground vehicle | moving-object-param | |
Fixed-wing | moving-object-param | |
Human | moving-object-param | |
Rotary-wing | moving-object-param | |
Surface | moving-object-param | |
Subsurface | moving-object-param | |
Cultural feature | moving-object-param | |
Missile | moving-object-param | |
Unit | moving-object-param | |
Unit Container | moving-object-param | vrf-object-param |
For descriptions of simulation object parameters, please see the descriptions of indi- vidual components in the OPD Editor online help.
This section lists the object type enumerations as listed in the header file objType- Enums.h. It is presented here primarily for customers who have purchased VR-Forces, but not the toolkit. Therefore we have departed from the typical header file format for readability.
The header file objTypeEnums.h contains the VR-Forces extensions to the DIS/RPR FOM enumerations. The enumerations specify individual, unit, and other object types. The sim object super-type is an enumeration used in the DtObjectType class (an exten- sion of the DtEntityType class). It extends the DIS/RPR FOM entity type enumeration by specifying the sort of object associated with the DtEntityType. Because object types are not guaranteed to be unique across all of the possible individual and unit types, the extra enumerated field provides a way to uniquely identify all objects in a VR-Forces simulation.
VR-Forces uses the value 3 in the object super-type for all of the units that it simulates.
Other 0 Individual 1
Unit 2
Disaggregated Unit 3
Aggregated Unit 4
Interaction 5
The enumeration for DtAggregateKind should start with 0, but VR-Forces starts with 10, to ensure that simulation object types will be unique.
Other 10
MilitaryHierarchy 11
CommonType 12
CommonMission 13
SimilarCapabilities 14
CommonLocation 15
DtSimArtPartKind 20
Extension of entity kind to represent non-simulation object objects, such as control objects (control points, routes, phase lines, obstacles, and so on.)
DtPointObjectKind 16
DtLinearObjectKind 17
DtArealObjectKind 18
DtCircleObjectKind 19
DtTextObjectKind 20
VR-Forces extends the enumeration to include DtAggregateCategoryForce, which represents the force level. All of the entries from Force through the end of the list, are extensions to the standard.
Other 0
IndividualVehicle 1
Element 2
Platoon 3
Battery 4
Company 5
Battalion 6
Regiment 7
Brigade 8
Division 9
Corps 10
Force 11
Team 12
Squad 13
Section 14
The Subcategory field enumerations for Kind field = Military Hierarchy specify the Echelon Type of the unit. Not all of the echelon types are applicable to each of the cate- gories.
In the following list, ForceFriendly, ForceOpposing, ForceNeutral, and ForceOther are extensions to the DIS/RPR FOM enumerations.
Other | 0 | ArmyAviationFixedWing | 13 |
CavalryTroop | 1 | ArmyAviationRotaryWing | 14 |
Armor | 2 | ArmyAttackHelicopter | 15 |
Infantry | 3 | AirCavalry | 16 |
MechanizedInfantry | 4 | ArmorHeavyTaskForce | 17 |
Cavalry | 5 | MotorizedRifle | 18 |
ArmoredCavalry | 6 | MechanizedHeavyTaskForce | 19 |
Artillery | 7 | CommandPost | 20 |
SelfPropelledArtillery | 8 | CEWI | 21 |
CloseAirSupport | 9 | TankOnly | 22 |
Engineer | 10 | ForceFriendly | 23 |
AirDefenseArtillery | 11 | ForceOpposing | 24 |
AntiTank | 12 |
The Specific field enumerations for Kind field = Military Hierarchy specify whether the unit contains a headquarters, and is enumerated as follows.
Noheadquarters 0
ContainsHeadquarters 1
Subcategories for use with the Kind field = DtPointObjectKind.
Other 0 ControlPoint 1
TargetPoint 2
Marker 3
Subcategories for use with the Kind field = DtLinearObjectKind.
Other 0 PhaseLine 1
Route 2
Subcategories for use with the Kind field = DtArealObjectKind.
Other 0 ControlArea 1
Obstacle 2
Kinds for Supertype interaction.
Other 0 Fire 1
Detonate 2
The tables in this appendix provide information about the systems provided with VR- Forces and list the simulation objects that use them.
VR-Forces Systems....................................................................................... D-2
The following tables list systems used for entity-level scenarios and aggregate-level scenarios:
Table D-1 lists all of the systems provided with the EntityLevel.sms and provides information about them.
Table D-2 lists each system and the entity types that use it.
Table D-3 lists systems and the scripted tasks configured in them for Enti- tyLevel.sms.
Table D-4 lists the systems for AggregateLevel.sms.
Table D-5 lists the system and entity types for AggregateLevel.sms.
Table D-6 lists systems and the scripted tasks configured in them for Aggre- gateLevel.sms.
Table D-1: System descriptions, EntityLevel.sms
System Category Entity Types Description
System Category Entity Types Description
120mm Gun weapon ground Turreted 120mm gun, typical of
tanks such as the M1A2. Fires M829A1-AP and M830-HEAT
rounds. Targets ground vehicles.
125mm Gun weapon ground Turreted 125mm gun, typical of
tanks such as the T-80. Fires both BM-9-AP and BM-14m- HEAT rounds. Targets ground vehicles.
14.5mm Quad Gun
weapon ground ADA Quad Machine Gun , multi-
barreled machine gun used for ADA. Found on ZPU-4. 14.5mm rounds. Targets Air entities.
25mm Gun weapon ground Turreted 25mm gun. Fires
M791-AP 25mm rounds. Targets ground vehicles.
30mm Gun weapon ground Turreted 30mm gun. Fires AT-
30mm rounds. Targets ground vehicles.
OTO Melara 76mm Naval Gun
Active RADAR Sensor
weapon surface Turreted indirect fire weapon.
Fires 76mm rounds on command.
sensor all Allows an entity to detect other objects through RADAR. Also publishes emitter beams that represent the emissions from the sensor.
Section XIV - Appendixes
D-2 VT MAK
Active SONAR Sensor
sensor all Allows an entity to detect other objects through SONAR.
Air Aggregate movement aggregate Basic movement capabilities for
any air-based aggregate, fixed wing or rotary wing.
Air Cushion movement ground Air cushion movement; allows
entity to cross both land and water.
Airborne Targeting RADAR
sensor fixed-wing, rotary-wing
RADAR used by aircraft to detect targets. Publishes an emitter beam.
Cargo Door other rotary-wing, fixed-wing, ground, surface
Sliding Door other rotary-wing, fixed-wing, ground, surface
Articulates the opening and closing of a cargo door.
Articulates the opening and closing of a sliding door.
Anti-Submarine Missile (Vertically Launched)
weapon surface Missile launched from deck of
ship, flies out to submarine target and drops a homing torpedo.
Building Default Damage
damage cultural- feature
Default damage system for a building.
CIS Air Defense Missile Package
CIS Attack Heli- copter Missile Package
CIS Attack/Strike Missile Package
CIS Counter Measures Launcher
weapon fixed-wing Missile launcher with loadout for
CIS air defense entity. Fires Aphid AA-8 missiles against air targets and Kedge AS-14 missiles against ground targets.
weapon rotary-wing Missile launcher with loadout for
CIS attack helicopter. Fires Archer AA-11 missiles against air targets and Spiral AT-6 missiles against ground targets.
weapon fixed-wing Missile launcher with loadout for
CIS attack/strike entity. Fires Aphid AA-8 missiles against air targets and Kerry AS-7 missiles against ground targets.
other all Allows an entity to launch counter measures for self defense. Configured with CIS flares and chaff.
CIS Fighter Bomber Bomb Bay
CIS Heavy Bomber Bomb Bay
weapon fixed-wing, rotary-wing
weapon fixed-wing, rotary-wing
Releases bombs in response to Release Bomb on Target, Loca- tion and Laser Spot tasks.
Configured to launch bombs manufactured in the Common- wealth of Independent States.
Releases bombs in response to Release Bomb on Target, Loca- tion and Laser Spot tasks.
Configured to launch bombs manufactured in the Common- wealth of Independent States.
Counter Measures Launcher
Vehicle Exposed Crew Suppression
other all Allows an entity to launch counter measures for self defense.
other ground Suppression model for vehicles
with exposed crew members.
Cruise Missile movement fixed-wing Cruise missile flight dynamics.
Fast and maneuverable, but with limited tasking capabilities.
DDG Embedded Support Craft (LAMPS/RHIB)
DI Laser Desig- nator
Exocet Cruise Missile Launcher (Forward Launched)
other all System that allows an entity to deploy and recover Embedded Entities appropriate to a ship with supporting LAMPS units.
other all A laser designator, which can aim a laser at targets. For use with a laser guided missile delivery system. This laser designator can be explicitly tasked to designate particular targets, or set to autonomous lasing mode. In autonomous lasing mode, the laser will auto- matically designate hostile ground vehicles.
weapon fixed-wing Launcher for Exocet anti-ship
cruise missiles. Launches missiles forward of the entity, appropriate for aircraft.
Exocet Cruise Missile Launcher (Vertically Launched)
weapon surface, ground
Launcher for Exocet anti-ship cruise missiles. Launches missiles at an upward angle, appropriate for ships.
Explosive Device weapon all Explosive device system. Allows
3 types of detonations -- instant, time-delayed, and proximity.
Section XIV - Appendixes
D-4 VT MAK
Fall From Sky Dynamics
movement all Movement dynamics for based on gravity and drag of object.
Fast Roping other all Allows troops to fast rope from
this vehicle.
Maverick Missile Launcher
weapon fixed-wing Fixed Maverick Missile Launcher.
Fires Air-To-Ground missiles at ground targets. Fixed to the entity (no turret) and always fires forward.
Sidewinder Missile Launcher
weapon fixed-wing, rotary-wing
Fixed Sidewinder Missile Launcher. Fires Air-To-Air missiles at air targets. Fixed to the entity (no turret) and always fires forward.
Fixed Wing Default Armor
damage fixed-wing Basic armor for a fixed-wing
aircraft.
Fighter Jet movement fixed-wing Fighter jet, such as the A-10. Heavy Plane movement fixed-wing Heavy plane flight dynamics,
such as a cargo plane.
High Maneuver- ability Fighter
Frictionless Gravity Dynamics
Frictionless Gravity Dynamics With Collisions
movement fixed-wing Highly maneuverable fighter jet,
such as the F-16.
movement all Movement dynamics solely based on gravity.
movement all Movement dynamics solely based on gravity.
GAU-8 Avenger weapon fixed-wing GAU-8 30mm gatling gun, found
on the U.S. A-10 ground attack aircraft. Used for attacking armor and other vehicles.
Gimbaled Visual Sensor
sensor all Allows an entity to detect other objects through visible light.
Grenade Warhead weapon all Grenade warhead. Will explode
based on the fuse of the muni- tion resource used to launch it.
Ground Aggre- gated Movement
aggregated aggregate Basic movement capabilities for
any ground-based aggregated unit, both vehicle and DI.
Ground Convoy Movement
disaggre- gated
aggregate Basic movement capabilities for
any ground-based convoy unit.
Ground Disaggre- gated Movement
disaggre- gated
aggregate Basic movement capabilities for
any ground-based disaggregated unit, both vehicle and DI.
Heavy Armor damage ground Heavy armored ground vehicle,
such as a tank.
Light Armor damage model
damage ground Component that computes
damage for lightly armored ground vehicles. Maps munition types to damage tables.
Tracks movement ground Movement model for ground
entities with tracks.
Tracks/Amphib- ious
movement ground Amphibious tracked vehicles that
can move over land and water.
No Armor damage ground, vrf object
Unarmored ground vehicle, such as a civilian vehicle.
Wheels (off road) movement ground Wheeled vehicle designed for off
road use, such as a HMMWV. Can switch into road following mode.
Wheels (road) movement ground Wheeled vehicle designed for on-
road use, such as a civilian car. Limited mobility off roads.
GSh-301 Cannon weapon fixed-wing GSh-301 30mm cannon used on
Russian attack aircraft. Used for attacking ground and air targets.
AK-47 weapon human Handheld AK-47 rifle. Targets
human entities.
AT4 weapon human Handheld AT4 Anti-Tank weapon. Targets ground vehicles and helicopters.
Throw Grenades other human Person throws a grenade M16 rifle weapon human Handheld M16 rifle. Targets
human entities.
Handheld M240B Machine Gun
weapon human Hand carried M240B 7.62mm
Machine Gun. Targets lifeforms.
M249 SAW weapon human M249 Squad Automatic
Weapon, 5.56mm fully auto- matic rifle. Targets lifeforms.
Handheld M60 Machine Gun
weapon human Hand carried M60 7.62mm
Machine Gun. Targets lifeforms.
Section XIV - Appendixes
D-6 VT MAK
RPG Launcher weapon human Handheld RPG Launcher.
Targets ground vehicles and heli- copters.
Handheld UAV movement fixed-wing Handheld / hand-launched UAV
such as the RQ-11 Raven.
Homing Torpedo Capability (Forward Launched)
weapon subsurface, surface, rotary-wing, fixed-wing
Homing torpedo capability. Launched from forward tubes.
Human Disaggre- gated Movement
disaggre- gated
aggregate Basic movement capabilities for
any human disaggregated unit, both vehicle and DI.
Suicide Vest weapon human Explosive device system that is
worn by a lifeform.
Flee From Explo- sions
other human Enables a behavior of automati-
cally fleeing from nearby explo- sions.
Human Default movement human Default movement dynamics for
human entities. Manages move- ment and posture.
IFF Transponder other all Sends IFF data, when turned on.
IFF is off by default.
IR Sensor sensor all Allows an entity to detect other
objects through Infrared.
Laser Designator other all A laser designator, which can
aim a laser at targets. For use with a laser guided missile delivery system. This laser designator can be explicity tasked to designate particular targets, or set to autonomous lasing mode. In autonomous lasing mode, the laser will auto- matically designate hostile ground vehicles.
Hydra 70 APKWS Launcher
weapon fixed-wing, rotary-wing
Launches APKWS rockets at targets that are lased with the laser code matching the one set in the launcher. Can only fire on targets designated with a laser.
Laser Guided Hell- fire Missile Launcher
weapon fixed-wing, rotary-wing
Launches Hellfire missiles at targets that are lased with the laser code matching the one set in the launcher. Can only fire on targets designated with a laser.
Laser Guided Missile Dynamics
movement missile Movement dynamics for a laser
guided missile. A missile using this type will require a laser on its target.
Default Armor damage human Basic damage model for lifeform
entities.
Lifeform Suppres- sion
Limit Entity Exis- tence
M1A2 Main Gun and MGs
other human Suppression model for lifeform
entities.
other all Used to control the life span of the object this system is attached to. Once it's life span is up the object is removed from the simulation.
weapon ground The turret for an M1A2 tank,
including the 120mm main gun, the coax MG, the commander's MG, and the loader's MG.
M2HB Machine Gun
weapon ground, surface
Turreted M2 .50 Caliber Machine Gun, typical of the secondary gun on tanks such as the M1A2. M2 12.7mm rounds. Targets life- forms. Also used on small boats and can target boats.
M203 Grenade Launcher
other human Launch grenade with attached
M203
M230 Chain Gun weapon ground,
rotary-wing
M230 chain gun, mounted on the AH-64 Apache. Fires High Explosive Dual Purpose rounds that can penetrate 2 inches of armor, and that fragment to kill soft targets.
M240 Machine Gun
weapon ground, rotary-wing
Vehicle mounted M240 7.62mm Machine Gun. Typical secondary gun on tanks such as the M1A2. Targets lifeforms and unarmored vehicles.
M250 smoke grenade launcher
other all Allows an entity to launch thermal obscuring white phos- phorous (WP) smoke.
Section XIV - Appendixes
D-8 VT MAK
M252 81mm
mortar
M270 MLRS
Launcher
M284 155mm
Cannon
weapon human, ground
weapon ground Turreted indirect fire weapon.
Fires M26 rockets on command. Targets must be at least 2km away.
weapon ground Turreted indirect fire weapon.
Fires 155mm M107 rounds on command. Targets must be at least 2km away.
M60 Machine Gun
weapon ground, rotary-wing
M60 7.62mm Machine Gun, typical vehicle machine gun. Replaced by M240. Targets life- forms and unarmored vehicles.
M61 Vulcan weapon fixed-wing M61 20mm gatling gun, found
on the U.S. attack aircraft. Used for attacking ground and air targets.
MAD Sensor sensor all Allows an entity to detect
Subsurface entities using Magnetic Anomaly Detection.
Missile Default Armor
damage missile, fixed- wing, scripted- movement
Basic armor for a missile.
Guided Missile Dynamics
movement missile Movement dynamics for a basic
guided missile.
Missile Warhead weapon fixed-wing,
subsurface, surface
Missile warhead. It explodes as soon as it hits another entity, the ground, or the surface of the water.
MK 45 Naval Gun weapon surface Turreted indirect fire weapon.
Fires 127mm rounds on command.
Naval Depth Charge Deploy- ment
weapon fixed-wing Depth charge release system for
naval depth charges.
Naval Mine Deployment
weapon fixed-wing, subsurface, surface
Mine release system for naval (underwater) mines.
Naval Mine Dynamics
movement all Movement dynamics based on gravity and drag of object. Will also allow the object to stop at a certain altitude.
Naval Mine Explo- sive Device
Naval Mine Sweep
Other Explosive Device
Passive RADAR Sensor
Passive SONAR Sensor
Patriot Missile Launcher
weapon bomb Naval Mine device system.
Allows 3 types of detonations -- instant, time-delayed, and prox- imity.
other surface Execute task to sweep and
disable naval mines.
other all Explosive device system for objects which do not normally have weapon systems. Allows 3 types of detonations -- instant, time-delayed, and proximity.
sensor all Allows an entity to detect other objects through RADAR. No emitters are published for this sensor.
sensor all Allows an entity to detect other objects through SONAR.
weapon ground Turreted Patriot Missile
Launcher. Targets air vehicles.
Pedestrian Crowd Movement
disaggre- gated- movement
all Movement capabilities for pedes- trian crowds.
Pedestrian Traffic Generator
other all Makes tasks available for pedes- trian traffic generation within the area defined by the object or the radius defined below.
Periscope other subsurface System that will allow modeling
of a periscope.
Rotary Wing Attack
Rotary Wing Default Armor
movement rotary-wing Attack Helicopter, such as the A- 64.
damage rotary-wing Basic armor for a rotary wing
aircraft.
Cargo movement rotary-wing General Cargo helicopter, such
as the CH-53 Super Stallion.
Quadcopter Heavy Lift
movement rotary-wing Movement dynamics for very
small, low altitude UAV and Quadcopter type vehicles
Quadcopter movement rotary-wing Movement dynamics for very
small, low altitude UAV and Quadcopter type vehicles
Dipping SONAR Sensor
sensor rotary-wing Allows an entity to detect other
objects through SONAR.
Section XIV - Appendixes
D-10 VT MAK
Utility movement rotary-wing General utility helicopter, such as
the UH-60 Blackhawk.
VTUAV movement rotary-wing General Vertical Takeoff
Unmanned Aerial Vehicle such as the Dragon Warrior.
SA-9 SAM Missile Launcher
weapon ground Turreted surface-to-air missile
launcher which fires SA-9 missiles. Targets air vehicles.
Scripted Move- ment
scripted- movement
scripted- movement
System that will allow for scripted movements.
Small boat movement surface Movement dynamics for small
boats.
Bomb Dynamics movement bomb Movement dynamics for a guided
smart bomb.
SONAR Sensor sensor all Allows an entity to detect other
objects through SONAR.
Sonobuoy Deployer
other all System that allows an entity to deploy sonobuoys.
Space Shuttle movement fixed-wing Based on the heavy plane flight
dynamics.
Spot Report Generator
Spot Report Receiver
Stinger Missile Launcher
Subsurface Entity Default
other all Allows the entity to send spot reports through its radio when its sensors detect other entities in the scenario.
other all Allows an entity to receive spot reports from other entities over the radio, and add these contacts to its list of known enti- ties. By default, spot reports expire after 5 minutes.
weapon ground Turreted Stinger Missile
Launcher. Targets air vehicles between 1km and 8km away, and fires guided stinger missiles at them.
damage subsurface Basic damage model for subsur-
face entities.
Subsurface movement subsurface Movement dynamics for a
subsurface vessel.
Surface Entity Default
damage surface Basic damage model for a
surface vessel.
Surface Disaggre- gated Movement
disaggre- gated
aggregate Basic movement capabilities for
any surface-entity-based disag- gregated unit.
Large Ship movement surface Movement dynamics for a large
ship.
Surface Multiple Hit Damage
Small Surface Ships
Tactical Radar Jammer
Tanker Refueling Boom
damage surface Hit point based surface damage
model.
damage surface Damage model for small boats
such as inflatables, sailboats, or small patrol boats.
other all Multi-mode ECM tactical jamming system.
other fixed-wing Articulates the deploying and
stowing of a refueling boom on a tanker aircraft.
Torpedo Warhead weapon subsurface,
surface
Torpedo warhead. It explodes as soon as it hits another entity, the ground, but not the surface of the water. Can also explode proximal to entity.
TOW Missile Launcher
weapon ground Turreted TOW Missile Launcher.
Targets ground vehicles.
US Fighter Bomber Bomb Bay
US Heavy Bomber Bomb Bay
Vertical SAM Missile Launcher
weapon fixed-wing, rotary-wing
weapon fixed-wing, rotary-wing
weapon ground, surface
Releases bombs in response to Release Bomb on Target, Loca- tion and Laser Spot tasks.
Configured to launch bombs manufactured in the United States of America.
Releases bombs in response to Release Bomb on Target, Loca- tion and Laser Spot tasks.
Configured to launch bombs manufactured in the United States of America.
Surface-to-air missile launcher which fires SM-2 missiles.
Targets cruise missiles.
Visual Sensor sensor all Allows an entity to detect other
objects through visible light.
Section XIV - Appendixes
D-12 VT MAK
120mm Gun AMX-10RC (No 3D), AMX-30 MBT, AMX-56 Leclerc MBT,
Arjun MBT (No 3D), C1 Ariete MBT (No 3D), Centauro B1 (No 3D), EE-9 Cascavel (No 3D), ERC 90 Sagaie (No 3D), FV4030/4 Challenger MBT, FV4034 Challenger 2 MBT (No 3D), K1A1 MBT (No 3D), Leopard 2 Tank, Merkava III MBT (No 3D), Merkava IV MBT (No 3D), MO-120RT-61 Mortar, Panhard AML- 245 (No 3D), PT-91 Twardy MBT (No 3D), Type 10 MBT (No
3D), Type 90 Kyu-maru MBT (No 3D)
125mm Gun MBT 2000 (No 3D), T-69 MBT, T-72 MBT, T-80 MBT, T-84 MBT (No 3D), T90A MBT (No 3D), Type 99 MBT (No 3D)
14.5mm Quad Gun
ZPU-4 AA Gun, ZSU-23-4 Shilka
25mm Gun Coyote APC (No 3D), Dardo IFV (No 3D), Freccia IFV (No 3D), FV101 Scorpion CVR, LAV III APC, M2A2 Bradley IFV, M3A2 Bradley CFV, MBT 2000 (No 3D), T-69 MBT, T-72 MBT, T-80 MBT, T-84 MBT (No 3D), T90A MBT (No 3D), Type 99 MBT (No 3D), VBCI APC (No 3D), Wiesel AWC (No 3D), XM7 FIST-
Bradley
30mm Gun ASCOD Ulan AIFV (No 3D), BMP-1 AFV, BMP-2 AFV, BTR-80
APC, BTR-90, Cadillac Gage Commando V-150 (No 3D), CV9035 AFV, FV 510 Warrior (No 3D), FV107 Scimitar, Pomornik (Zubr)-class LCAC (No 3D), Type 85 (YW 531H) APC (No 3D)
OTO Melara 76mm Naval Gun
Brandenburg-class Frigate (No 3D)
Active RADAR Sensor
Admiral Grigorovich-class Frigate (No 3D), Ahmad Yani-class Frigate, Aircraft Carrier, Albatros-class Fast Attack (No 3D), Patriot Radar AN/MPQ-65, Aquitaine-class Frigate (No 3D), Arleigh Burke-class Destroyer, Asagiri-class Destroyer (No 3D), Bay-class DLS (No 3D), Bay-class Patrol Boat (No 3D), Sentinel R1 (No 3D), Brandenburg-class Frigate (No 3D), Braunschweig- class Corvette (No 3D), Bremen-class Frigate (No 3D), Cape- class Patrol Boat (No 3D), Charles De Gaulle R91 (No 3D), Dabur-class Patrol Boat (No 3D), De Zeven Provincien Class Frigate (No 3D), Delhi-class Destroyer (No 3D), Durand de la Penne-class Destroyer (No 3D), Echo-class Survey Ship (No 3D), Eridan-class Minehunter (No 3D), F-22P Zulfiquar-class Frigate (No 3D), Fatahillah-class Frigate (No 3D), Floreal-class Frigate (No 3D), Flyvefisken-class Patrol Boat (No 3D), Frankenthal- class Minehunter (No 3D), LCS Freedom Class (No 3D), Fridtjof Nansen-class (No 3D), Gaeta-class Minehunter, Gepard-class Frigate (No 3D), Grisha-class Corvette (No 3D), Guided Missile Destroyer, Krivak-class Guided Missile Frigate, Halifax-class Frigate (No 3D), Hamina-class Fast Attack (No 3D), Hauk-class Fast Attack (No 3D), Henry J Kaiser-class Oiler (No 3D), Holland Class OPV (No 3D), Horizon-class Destroyer (No 3D), Hunt-class Minehunter (No 3D), LCS Independence Class (No 3D), Invin- cible-class Carrier (No 3D), Iroquois-class Destroyer (No 3D), Island-class Patrol Vessel (No 3D), Jacinto-class Corvette (No 3D), L-class Frigate (No 3D), Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), KCR-40 Clurit-class Fast Attack (No 3D), Keeper-class (WLM) (No 3D), Khareff-class Corvette (No 3D), Kingston-class Patrol vessel, Kirov-class Guided Missile Cruiser (No 3D), Kolkata-class Destroyer (No 3D), Kuznetsov- class (No 3D), L 14 Albion (No 3D), La Fayette-class Frigate (No 3D), Legend Class (WMSL), LPH01 Ocean (No 3D), Harpers Ferry-class LSD, Lupo-class Frigate (No 3D), Maestrale-class Frigate (No 3D), Milgem Class Corvette, Patriot Air Defense System (PAC-3), Osprey-class Mine CMS (No 3D), Mistral Class AAS (No 3D), Moudge-class Frigate (No 3D), Murasame-class Destroyer (No 3D), Nanuchka III-class (No 3D), Neustrashimyy- class Frigate (No 3D), Nimitz-class Carrier, Niteroi-class Frigate (No 3D), Oksoy-class Minehunter (No 3D), Pauk-class Corvette (No 3D), Pomornik (Zubr)-class LCAC (No 3D), Queen Elizabeth- class Carrier (No 3D), River-class Patrol Vessel (No 3D), Saar 4- class Missile Boat (No 3D), Saar 4.5-class Missile Boat (No 3D), Saar 5-class Corvette (No 3D), Sachsen-class Frigate (No 3D), Sandown-class Minehunter (No 3D), Sentinel-class (WPC) (No 3D), Sigma 9113-class Frigate, Skjold-class Patrol (No 3D), Slava-class Guided Missile Cruiser (No 3D), Sovremennyy-class Destroyer, Steregushchiy-class Frigate (No 3D), Super Dvora Mark II (No 3D), Tarantul-class Corvette (No 3D), Tiger-class Fast Attack Craft (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 42 Destroyer (No 3D), Type 45 Destroyer, Type 22 Frigate (No 3D), Type 23 Frigate, Udaloy-class Destroyer, National Security Cutter, Hamilton Class Cutter WHEC, Victor II- class Submarine (No 3D), Victory-class Corvette (No 3D), Marine Protector Class Patrol Boat
Section XIV - Appendixes
D-14 VT MAK
Active SONAR Sensor
Air Aggregate
Ahmad Yani-class Frigate, Alta-class Minehunter (No 3D), Aquit- aine-class Frigate (No 3D), Brandenburg-class Frigate (No 3D), Bremen-class Frigate (No 3D), De Zeven Provincien Class Frigate (No 3D), Eridan-class Minehunter (No 3D), Flyvefisken-class Patrol Boat (No 3D), Frankenthal-class Minehunter (No 3D), Fridtjof Nansen-class (No 3D), Grisha-class Corvette (No 3D), Hamina-class Fast Attack (No 3D), L-class Frigate (No 3D), Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), La Fayette-class Frigate (No 3D), Legend Class (WMSL), Niteroi- class Frigate (No 3D), Oksoy-class Minehunter (No 3D), Pauk- class Corvette (No 3D), Sachsen-class Frigate (No 3D), Sigma 9113-class Frigate, Sonobuoy (Passive), Steregushchiy-class Frigate (No 3D), National Security Cutter, Hamilton Class Cutter WHEC
Air Cushion Centauro B1 (No 3D), , LCAC, Pomornik (Zubr)-class LCAC (No 3D)
Airborne Targeting RADAR
A-10 Thunderbolt, A-4 Skyhawk (No 3D), AMX (No 3D), AV-8B Harrier II, B-2 Spirit, BAE CT-155 Hawk (No 3D), C-130 Hercules, C-17 Globemaster III (No 3D), C-5 Galaxy (No 3D), Chengdu J-7 (No 3D), Cypher VTUAV, Dassault Atlantic (No 3D), Dragon Warrior VTUAV, E-2 Hawkeye, E-3 Sentry, EA-6B Prowler, Eurofighter Typhoon, F-117A Nighthawk, F-15 Eagle, F-16A Fighting Falcon, F-22 Raptor (No 3D), F-35 Lightning II, F/A-18 Hornet, Harbin SH-5 ASW (No 3D), Hermes 450 (No 3D), Maveric UAS (No 3D), MiG-27 Flogger, MiG-29 Fulcrum, Mirage 2000, Mirage F1, MQ-4C Triton, MQ-8B Fire Scout, MQ- 9 Reaper UAV, Nanchang Q-5 (No 3D), P-3 Orion, MQ-1 Pred- ator, RQ-11 Raven UAV, RQ-4 Global Hawk UAV, RQ-7 Shadow UAV (No 3D), SAGEM Sperwer (No 3D), ScanEagle UAV (No 3D), Shenyang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), SU-25 Frogfoot, SU-27 Flanker, Su-37 Flanker, Tornado ADV (No 3D), Tu-160 Blackjack (No 3D), Xian H-6 Badger (No 3D), Xian JH-7 (No 3D)
Cargo Door CH-149 Cormorant, CH-53E Super Stallion Sliding Door CH-149 Cormorant
Anti-Submarine Missile (Vertically Launched)
Building Default Damage
CIS Air Defense Missile Package
CIS Attack Heli- copter Missile Package
Arleigh Burke-class Destroyer, Kirov-class Guided Missile Cruiser (No 3D), Lupo-class Frigate (No 3D), Maestrale-class Frigate (No 3D), Pauk-class Corvette (No 3D), Type 23 Frigate
Bottle, Building Warehouse Steel, POL Storage Tank, Shooting Target, Tower Radio
MiG-29 Fulcrum, SU-27 Flanker
KA-50 Hokum, Mi-24 Hind, Mi-28 Havoc
CIS Attack/Strike Missile Package
CIS Counter Measures Launcher
CIS Fighter Bomber Bomb Bay
CIS Heavy Bomber Bomb Bay
Counter Measures Launcher
Chengdu J-7 (No 3D), , MiG-27 Flogger, Nanchang Q-5 (No 3D), Shenyang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), SU-25 Frogfoot, Su-37 Flanker
Chengdu J-7 (No 3D), , KA-50 Hokum, Mi-17 Hip (No 3D), Mi- 24 Hind, Mi-28 Havoc, MiG-27 Flogger, MiG-29 Fulcrum, Nanchang Q-5 (No 3D), Shenyang J-11 Flanker (No 3D), Shen- yang J-8 Finback (No 3D), SU-25 Frogfoot, SU-27 Flanker, Su- 37 Flanker, Tu-160 Blackjack (No 3D)
Chengdu J-7 (No 3D), , MiG-27 Flogger, MiG-29 Fulcrum, Nanchang Q-5 (No 3D), Shenyang J-11 Flanker (No 3D), Shen- yang J-8 Finback (No 3D), SU-25 Frogfoot, SU-27 Flanker, Su- 37 Flanker, Tu-160 Blackjack (No 3D)
A-10 Thunderbolt, A-4 Skyhawk (No 3D), AgustaWestland AW101 (No 3D), AgustaWestland AW109 (No 3D), AH-1W SuperCobra, AH-64A Apache, AH-6 Little Bird (No 3D), AMX (No 3D), Antonov-class (No 3D), AS 550 Fennec (No 3D), AS- 365 Dauphin (No 3D), AS-565 Panther (No 3D), AV-8B Harrier II, BAE CT-155 Hawk (No 3D), Bell 412 (No 3D), Bell 206
JetRanger (No 3D), Bell 406 (No 3D), C-130 Hercules, C-17 Globemaster III (No 3D), C-5 Galaxy (No 3D), CH-148 Cyclone (No 3D), CH-46E Sea Knight, CH-47 Chinook (No 3D), CH-53E Super Stallion, Chengdu J-7 (No 3D), Dassault Atlantic (No 3D), E-2 Hawkeye, EA-6B Prowler, EC 135 (No 3D), EC 635 (No 3D),
EC145 (No 3D), EC665 Eurocopter Tiger (No 3D), EH101 Merlin (No 3D), Eurofighter Typhoon, F-15 Eagle, F-16A Fighting Falcon, F-22 Raptor (No 3D), F-35 Lightning II, F/A-18 Hornet, Harbin SH-5 ASW (No 3D), HH-65 Dolphin (No 3D), Il-76 Candid (No 3D), KA-50 Hokum, MD 500 (No 3D), MH-47 Chinook (No
3D), MH-60L Black Hawk DAP (No 3D), MH-60 Black Hawk, MH-6 Little Bird (No 3D), Mi-17 Hip (No 3D), Mi-24 Hind, Mi-28 Havoc, Mi-2 Hoplite, MiG-27 Flogger, MiG-29 Fulcrum, Mirage 2000, Mirage F1, Nanchang Q-5 (No 3D), OH-58 Kiowa, P-3 Orion, RAH-66 Comanche, SA 330 Puma (No 3D), SA 342 Gazelle (No 3D), SH-3 Sea King (No 3D), SH-60 Seahawk, Shen- yang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), SU- 25 Frogfoot, SU-27 Flanker, Su-37 Flanker, Tornado ADV (No 3D), Tu-160 Blackjack (No 3D), UH-1N Twin Huey (No 3D), UH- 60 Blackhawk, UH-72 Lakota (No 3D), V-22 Osprey (No 3D), Westland Lynx (No 3D), WS-61 Sea King (No 3D), Xian JH-7 (No 3D)
Section XIV - Appendixes
D-16 VT MAK
Vehicle Exposed Crew Suppression
AAVC7A1 Landing Vehicle, Dardo IFV (No 3D), Freccia IFV (No 3D), HMMWV with Avenger, HMMWV with M2, HMMWV with TOW launcher, L-118 Howitzer (No 3D), LAV III APC, Leopard 2 Tank, LG1 Howitzer (No 3D), M-71 Howitzer (No 3D), M113 APC, M1A2 Abrams MBT, M252 Mortar, M577A2 Command Post, Technical Truck, VAB APC, ZPU-4 AA Gun
Cruise Missile Exocet Cruise Missile, RUR-5 ASROC
DDG Embedded Support Craft (LAMPS/RHIB)
DI Laser Desig- nator
Exocet Cruise Missile Launcher (Forward Launched)
Exocet Cruise Missile Launcher (Vertically Launched)
Arleigh Burke-class Destroyer, Kirov-class Guided Missile Cruiser (No 3D), Slava-class Guided Missile Cruiser (No 3D)
DI Lasing (CIS), DI Lasing (US)
Dassault Atlantic (No 3D), MiG-27 Flogger, Mirage 2000, SU-25 Frogfoot, Su-37 Flanker, Tu-160 Blackjack (No 3D), Xian H-6 Badger (No 3D), Xian JH-7 (No 3D)
Aquitaine-class Frigate (No 3D), Arleigh Burke-class Destroyer, Brandenburg-class Frigate (No 3D), Braunschweig-class Corvette (No 3D), Durand de la Penne-class Destroyer (No 3D), Fatahillah- class Frigate (No 3D), Floreal-class Frigate (No 3D), Guided Missile Destroyer, Krivak-class Guided Missile Frigate, Halifax- class Frigate (No 3D), Hauk-class Fast Attack (No 3D), Horizon- class Destroyer (No 3D), Iroquois-class Destroyer (No 3D), KD- III-class Destroyer (No 3D), Khareff-class Corvette (No 3D), Kirov-class Guided Missile Cruiser (No 3D), Kolkata-class Destroyer (No 3D), La Fayette-class Frigate (No 3D), Moudge- class Frigate (No 3D), Niteroi-class Frigate (No 3D), Saar 4-class Missile Boat (No 3D), Saar 4.5-class Missile Boat (No 3D), Saar 5-class Corvette (No 3D), Sigma 9113-class Frigate, Skjold- class Patrol (No 3D), Sovremennyy-class Destroyer, Tiger-class Fast Attack Craft (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 42 Destroyer (No 3D), Type 22 Frigate (No 3D), Udaloy-class Destroyer, Victory-class Corvette (No 3D)
Explosive Device Car Bomb, Duffle Bag, Naval Mine, Quickstrike Mk 65, Roadside IED, Sea Lance ASW, Suicide Bomber
Fall From Sky Dynamics
CIS Chaff, CIS Flare, US Chaff, US Flare
Fast Roping CH-149 Cormorant, MH-60 Black Hawk, SH-60 Seahawk, UH- 60 Blackhawk
Maverick Missile Launcher
A-10 Thunderbolt, A-4 Skyhawk (No 3D), AV-8B Harrier II, EA- 6B Prowler, Eurofighter Typhoon, F-117A Nighthawk, F-15 Eagle, F-16A Fighting Falcon, F-22 Raptor (No 3D), F-35 Light- ning II, F/A-18 Hornet, Mirage F1, P-3 Orion, MQ-1 Predator, Tornado ADV (No 3D), Xian H-6 Badger (No 3D), Xian JH-7 (No 3D)
Sidewinder Missile Launcher
Fixed Wing Default Armor
A-10 Thunderbolt, A-4 Skyhawk (No 3D), AMX (No 3D), AV-8B Harrier II, BAE CT-155 Hawk (No 3D), Eurofighter Typhoon, F- 117A Nighthawk, F-15 Eagle, F-16A Fighting Falcon, F-22 Raptor (No 3D), F-35 Lightning II, F/A-18 Hornet, Mirage F1, Tornado ADV (No 3D), Xian JH-7 (No 3D)
A-10 Thunderbolt, A-4 Skyhawk (No 3D), Ababil UAV (No 3D), Airbus 310, Airbus 320 - American Airlines, Airbus 320 - British Airways, Airbus 320 - Lufthansa, Airbus 320 - Singapore Airlines, Airbus 380 (No 3D), AMX (No 3D), AT-802 (No 3D), AV-8B Harrier II, B-2 Spirit, Beechcraft 36 Bonanza (No 3D), Beechcraft C-12 Super King (No 3D), Beechcraft T-6 (No 3D), BN-2 Islander (No 3D), Boeing 707, Boeing 737 British Midland, Boeing 747-400, Boeing 757 (No 3D), Boeing 767 (No 3D), Boeing 777 (No 3D), Boeing 787 (No 3D), Bombardier CL-600 (No 3D), Bombardier DHC-8 (No 3D), Sentinel R1 (No 3D), Bombardier CRJ100 Conrad Air, Bombardier CRJ200 Air France, C-130 Hercules, C-17 Globemaster III (No 3D), C-5 Galaxy (No 3D), CASA C-212 Aviocar (No 3D), Cessna 172 Skyhawk, Cessna Citation (No 3D), Chengdu J-7 (No 3D), Dassault Atlantic (No 3D), Dassault Mystere-Falcon 20 (No 3D), Dassault Mystere-Falcon 900 (No 3D), Dornier DO 228-200 LGW, E-2 Hawkeye, E-3 Sentry, EA-6B Prowler, EADS CASA C-295 (No 3D), EMT Aladin (No 3D), EMT Luna (No 3D), Eurofighter Typhoon, F-117A Nighthawk, F-15 Eagle, F-16A Fighting Falcon, F-22 Raptor (No 3D), F-35 Lightning II, F/A-18 Hornet, Gulfstream G550 (No 3D), Harbin SH-5 ASW (No 3D), Hermes 450 (No 3D), IAI 1124 Sea Scan (No 3D), KC-135 Stratotanker, Lockheed L-1011 (No 3D), Maveric UAS (No 3D), MiG-27 Flogger, MiG-29 Fulcrum, Mirage 2000, Mirage F1, Mohajer UAV (No 3D), MQ-4C Triton, MQ-9 Reaper UAV, Nanchang Q-5 (No 3D), P-3 Orion, MQ-1 Predator, RDE KZO (No 3D), RQ-11
Raven UAV, RQ-4 Global Hawk UAV, RQ-7 Shadow UAV (No 3D), SAGEM Sperwer (No 3D), ScanEagle UAV (No 3D), Shen- yang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), Space Shuttle, SU-25 Frogfoot, SU-27 Flanker, Su-37 Flanker, Tornado ADV (No 3D), Tu-160 Blackjack (No 3D), Ultralight Trike, Xian H-6 Badger (No 3D), Xian JH-7 (No 3D)
Fighter Jet A-10 Thunderbolt, AV-8B Harrier II, B-2 Spirit, Chengdu J-7 (No 3D), F-117A Nighthawk, MiG-27 Flogger, Nanchang Q-5 (No 3D), Shenyang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), SU-25 Frogfoot, Su-37 Flanker, Tu-160 Blackjack (No 3D), Xian H-6 Badger (No 3D)
Section XIV - Appendixes
D-18 VT MAK
Heavy Plane Airbus 310, Airbus 320 - American Airlines, Airbus 320 - British Airways, Airbus 320 - Lufthansa, Airbus 320 - Singapore Airlines, Airbus 380 (No 3D), AT-802 (No 3D), Beechcraft 36 Bonanza (No 3D), Beechcraft C-12 Super King (No 3D), Beech- craft T-6 (No 3D), BN-2 Islander (No 3D), Boeing 707, Boeing 737 British Midland, Boeing 747-400, Boeing 757 (No 3D), Boeing 767 (No 3D), Boeing 777 (No 3D), Boeing 787 (No 3D), Bombardier CL-600 (No 3D), Bombardier DHC-8 (No 3D), Sentinel R1 (No 3D), Bombardier CRJ100 Conrad Air, Bombar- dier CRJ200 Air France, C-130 Hercules, C-17 Globemaster III (No 3D), C-5 Galaxy (No 3D), CASA C-212 Aviocar (No 3D), Cessna 172 Skyhawk, Dassault Atlantic (No 3D), Dornier DO 228-200 LGW, E-2 Hawkeye, E-3 Sentry, EA-6B Prowler, EADS CASA C-295 (No 3D), Gulfstream G550 (No 3D), Harbin SH-5 ASW (No 3D), IAI 1124 Sea Scan (No 3D), KC-135 Strato-
tanker, Lockheed L-1011 (No 3D), P-3 Orion, Ultralight Trike
High Maneuver- ability Fighter
Frictionless Gravity Dynamics
Frictionless Gravity Dynamics With Collisions
A-4 Skyhawk (No 3D), AMX (No 3D), BAE CT-155 Hawk (No
3D), Canadair CT-114 (No 3D), Cessna Citation (No 3D), Dassault Mystere-Falcon 20 (No 3D), Dassault Mystere-Falcon 900 (No 3D), Eurofighter Typhoon, F-15 Eagle, F-16A Fighting Falcon, F-22 Raptor (No 3D), F-35 Lightning II, F/A-18 Hornet, Hermes 450 (No 3D), MiG-29 Fulcrum, Mirage 2000, Mirage F1, MQ-4C Triton, MQ-9 Reaper UAV, MQ-1 Predator, RQ-4 Global Hawk UAV, SAGEM Sperwer (No 3D), SU-27 Flanker, Tornado ADV (No 3D), Xian JH-7 (No 3D)
76mm Shell, M107 155mm, M26 Rocket, M374A2 81mm, M433, M583A1, M651, M713, M715, M716
M18_Green Smoke Grenade, M18_Red Smoke Grenade, M18_Violet Smoke Grenade, M18_Yellow Smoke Grenade, M67 hand grenade, M83 White Smoke, M84 Flash Bang
GAU-8 Avenger A-10 Thunderbolt
Gimbaled Visual Sensor
MQ-8B Fire Scout, MQ-9 Reaper UAV, MQ-1 Predator, SAGEM Sperwer (No 3D)
Grenade Warhead M18_Green Smoke Grenade, M18_Red Smoke Grenade, M18_Violet Smoke Grenade, M18_Yellow Smoke Grenade, M67 hand grenade, M83 White Smoke, M84 Flash Bang
Ground Aggre- gated Movement
Ground Convoy Movement
ADA Plt (CIS), ADA Plt (US), Armor Co (CIS), Armor Co (US),
Armor Co HQ (CIS), Armor Co HQ (US), Armor Plt (CIS), Armor Plt (US), COLT Team (CIS), COLT Team (US), CSS Plt (CIS), CSS Plt (US), DI Plt (CIS), DI Squad (CIS), DI Squad (US), FA
Battery (US), Ground Unit, MI Plt (CIS), MI Plt with IFV (US), USMC FT, USMC SQD, US Army LtInf FT, US Army LtInf SQD,
US Army Mech FT A (Javelin), US Army Mech FT B, US Army Mech SQD
Convoy
Ground Disaggre- gated Movement
ADA Plt (CIS), ADA Plt (US), Armor Co (CIS), Armor Co (US),
Armor Co HQ (CIS), Armor Co HQ (US), Armor Plt (CIS), Armor Plt (US), CSS Plt (CIS), CSS Plt (US), DI Squad (US), FA Battery (US), Ground Unit, MI Plt (CIS), MI Plt with IFV (US)
Heavy Armor AMX-30D (No 3D), AMX-30 MBT, AMX-56 Leclerc MBT, Aravis MRAP (No 3D), Arjun MBT (No 3D), ASCOD Ulan AIFV (No 3D),
ATF Dingo (No 3D), Badger AEV (No 3D), Beaver AVLB (No 3D), Bergepanzer 2 ARV (No 3D), Buffalo MRAP III, Buffel ARV (No 3D), Bushmaster PMV (No 3D), C1 Ariete MBT (No 3D), CV9035 AFV, DNG/DCL (No 3D), EE-9 Cascavel (No 3D),
Freccia IFV (No 3D), Fuchs APC (No 3D), FV4030/4 Challenger MBT, FV4034 Challenger 2 MBT (No 3D), GTK Boxer APC (No 3D), K1A1 MBT (No 3D), Leopard 2 Tank, M1A2 Abrams MBT, MBT 2000 (No 3D), Merkava III MBT (No 3D), Merkava IV MBT (No 3D), MOWAG Eagle (No 3D), MRAP-ATV, MRAP-CAT II
Cougar, MRAP-CAT I MaxxPro, PT-91 Twardy MBT (No 3D), Puma AFV (No 3D), RG-31 Nyala (No 3D), T-69 MBT, T-72 MBT, T-80 MBT, T-84 MBT (No 3D), T90A MBT (No 3D),
Taurus ARV (No 3D), Type 10 MBT (No 3D), Type 90 Kyu-maru MBT (No 3D), Type 99 MBT (No 3D), VM 90 LSVW (No 3D)
Light Armor damage model
2S19 Msta-S (No 3D), Aardvark JSFU (No 3D), AAVC7A1
Landing Vehicle, Achzarit APC (No 3D), AMX-10RC (No 3D), AS-90 Artillery, ASTROS II MLRS (No 3D), AUF1 155mm
Howitzer (No 3D), Auverland A4 AVL (No 3D), Bandvagn 206 (No 3D), Bison APC (No 3D), BMP-1 AFV, BMP-2 AFV, BTR-60
APC, BTR-80 APC, BTR-90, Cadillac Gage Commando V-150 (No 3D), CAESAR SP Howitzer, Centauro B1 (No 3D), Cougar FSV, Coyote APC (No 3D), Dardo IFV (No 3D), ERC 90 Sagaie (No 3D), ESK Mungo (No 3D), FV 510 Warrior (No 3D), FV101
Scorpion CVR, FV107 Scimitar, FV432 APC (No 3D), Grizzly APC (No 3D), Husky ARV (No 3D), L-118 Howitzer (No 3D), LAPV Enok (No 3D), LAV III APC, LG1 Howitzer (No 3D), M-71
Howitzer (No 3D), M109 Howitzer, M1126 Stryker ICV, M113 APC, M252 Mortar, M270 MLRS, M2A2 Bradley IFV, M3A2
Bradley CFV, M577A2 Command Post, M777 Howitzer (No 3D), M88 Medium Recovery Vehicle, M993 MLRS, M9 ACE, Mamba APC (No 3D), MO-120RT-61 Mortar, MOWAG Duro (No 3D), MT-LB APC, Namer APC (No 3D), Panhard AML-245 (No 3D),
Panhard M3 APC (No 3D), Panther CLV (No 3D), Panzerhaubitze 2000 Howitzer, Patria AMV (No 3D), Pegaso 3046 APC (No 3D), PLZ-45 Howitzer (No 3D), Puma CEV (No 3D), Rapier SAM (No 3D), SA-15 Gauntlet SAM, SA-19 Grison, SA-6 Gainful SAM, SA-9 Gaskin SAM System, Type 85 (YW 531H) APC (No 3D), VAB APC, VBCI APC (No 3D), VBL ATV, Wiesel AWC (No
3D), WZ551 APC (No 3D), XM7 FIST-Bradley, ZPU-4 AA Gun,
ZSU-23-4 Shilka
Section XIV - Appendixes
D-20 VT MAK
Tracks 2S19 Msta-S (No 3D), Aardvark JSFU (No 3D), Achzarit APC (No 3D), AMX-30D (No 3D), AMX-30 MBT, AMX-56 Leclerc
MBT, Arjun MBT (No 3D), AS-90 Artillery, ASCOD Ulan AIFV (No 3D), ASTROS II MLRS (No 3D), AUF1 155mm Howitzer (No
3D), Badger AEV (No 3D), Bandvagn 206 (No 3D), Beaver AVLB (No 3D), Bergepanzer 2 ARV (No 3D), Bison APC (No 3D), BMP- 1 AFV, BMP-2 AFV, BTR-60 APC, BTR-80 APC, BTR-90, Buffel
ARV (No 3D), C1 Ariete MBT (No 3D), Cougar FSV, Coyote APC (No 3D), CV9035 AFV, DNG/DCL (No 3D), FV 510 Warrior (No
3D), FV101 Scorpion CVR, FV107 Scimitar, FV4030/4 Chal- lenger MBT, FV4034 Challenger 2 MBT (No 3D), FV432 APC (No 3D), Grizzly APC (No 3D), GTK Boxer APC (No 3D), Husky ARV (No 3D), K1A1 MBT (No 3D), LAV III APC, Leopard 2 Tank,
LG1 Howitzer (No 3D), M-71 Howitzer (No 3D), M109 Howitzer, M1A2 Abrams MBT, M252 Mortar, M2A2 Bradley IFV, M3A2 Bradley CFV, M577A2 Command Post, M777 Howitzer (No 3D), M88 Medium Recovery Vehicle, M993 MLRS, M9 ACE, Mamba APC (No 3D), MBT 2000 (No 3D), Merkava III MBT (No 3D), Merkava IV MBT (No 3D), MT-LB APC, Namer APC (No 3D),
Panhard AML-245 (No 3D), Panhard M3 APC (No 3D), Panzer- haubitze 2000 Howitzer, Patria AMV (No 3D), Pegaso 3046 APC (No 3D), PLZ-45 Howitzer (No 3D), PT-91 Twardy MBT (No 3D), Puma CEV (No 3D), Rapier SAM (No 3D), Renault GBC 180 Truck (No 3D), SA-15 Gauntlet SAM, SA-19 Grison, SA-6 Gainful SAM, T-69 MBT, T-72 MBT, T-80 MBT, T-84 MBT (No 3D), T90A MBT (No 3D), Taurus ARV (No 3D), TRM 1000 Truck (No 3D), Type 85 (YW 531H) APC (No 3D), Type 10 MBT
(No 3D), Type 90 Kyu-maru MBT (No 3D), Type 99 MBT (No 3D), VAB APC, VBL ATV, VLRA 4x4 Truck (No 3D), VLRA 6x6 Truck (No 3D), WZ551 APC (No 3D), XM7 FIST-Bradley, ZSU-
23-4 Shilka
Tracks/Amphib- ious
AAVC7A1 Landing Vehicle
No Armor Actros AHSVS (No 3D), Aircraft Baggage Conveyor, Aircraft Baggage Truck, Aircraft Baggage Wagon, Aircraft Catering Truck, Aircraft Follow Me Car, Aircraft High Loader Dolly, Aircraft Mobile Stairs, Aircraft Tow Tractor 1, Aircraft Tow Tractor 2, Aircraft Towbar, Airport Bus, Ambulance, Patriot Radar AN/MPQ-65, Auto Rickshaw, BMW 320D Series, BMW 328i Series, BMW M5 Series, BMW X3 Series, BMW X5 Series, Bulldozer, Bus MBTA, Bus, BV206 SUSV (No 3D), Camel, Car Bomb, Chevrolet Caprice, Chevy Tahoe, Civilian vehicle, CUCV II (No 3D), Defense Satellite, Duffle Bag, Federal Express Truck, Female On Bike, Fenneck, Fiat 124, Fire Engine, Food Truck, Ford Aircraft Oil Truck, Ford Ambulance (Boston), Ford Ambu- lance, Ford Contour, Ford Pickup Truck (White), Ford Pickup Truck (Red), Fuel Tanker Trailer, G-Wagen (No 3D), GAZ-66 Truck, GAZ-69 Utility Vehicle, GMC Yukon, Goat, HMMWV Utility Vehicle, HMMWV with Avenger, HMMWV with M2, HMMWV with Shelter, HMMWV with TOW launcher, Honda Accord (Silver), Honda Accord, Horse, Iveco LMV (No 3D), Jackal MWMIK (No 3D), Jingle Truck, Ladder Truck, Land Rover Wolf (No 3D), Land Rover, LCAC, LIV (SO) Serval (No 3D), M- Gator ATV, M1028 FMTV Cargo Truck, M35 Truck, M58 MICLIC, M939A2 5-Ton Truck, M977 HEMTT Cargo Truck, M978 HEMTT Fuel Truck, Male On Motorbike, Male On Bike, Mercedes M Series, MILCOTTS Silverado (No 3D), M901 Patriot Launcher, Patriot Air Defense System (PAC-3), Mini Cooper Silver, Mule, Navistar 7000 (No 3D), Nissan Maxima, Nuclear Power Plant, Paddy Wagon, EPP-III Patriot Power Generator, Patriot Engagement Control Sys, Police Car (BMW M5), Police Cruiser (Chevy), Police Paddy Wagon, Police Tactical Van, Police Car (Ford), Pomornik (Zubr)-class LCAC (No 3D), Renault GBC 180 Truck (No 3D), Roadside IED, Safir Military Vehicle, Sheep, Taxicab, Technical Truck, Toyota Corolla, Toyota Pickup, Tractor Trailer Cab, Tractor Trailer with Cab, TRM 1000 Truck (No 3D), URO VAMTAC (No 3D), US Postal Truck, Van (Blue), Van (Green), Van (Red), Van (White), VLRA 4x4 Truck (No 3D), VLRA 6x6 Truck (No 3D), Volkswagen Golf (Black), Volkswagen Golf (White), Volkswagen Passat, Water Buffalo, ZIL-135 8x8 Truck
Section XIV - Appendixes
D-22 VT MAK
Wheels (off road) Actros AHSVS (No 3D), AMX-10RC (No 3D), Aravis MRAP (No 3D), ATF Dingo (No 3D), Auverland A4 AVL (No 3D), Buffalo MRAP III, Bushmaster PMV (No 3D), Cadillac Gage Commando V-150 (No 3D), CAESAR SP Howitzer, Camel, Cow, CUCV II (No 3D), Dardo IFV (No 3D), EE-9 Cascavel (No 3D), ERC 90 Sagaie (No 3D), ESK Mungo (No 3D), Female On Bike, Fenneck, Fire Engine, Ford Ambulance (Boston), Ford Ambulance, Ford Pickup Truck (White), Ford Pickup Truck (Red), Freccia IFV (No 3D), Fuchs APC (No 3D), GAZ-69 Utility Vehicle, GMC Yukon, Goat, HMMWV Utility Vehicle, HMMWV with Avenger, HMMWV with M2, HMMWV with Shelter, HMMWV with TOW launcher, Horse, Iveco LMV (No 3D), Jackal MWMIK (No 3D), Land Rover Wolf (No 3D), Land Rover, LAPV Enok (No 3D), LIV (SO) Serval (No 3D), M1126 Stryker ICV, M113 APC, M270 MLRS, M35 Truck, M58 MICLIC, M939A2 5-Ton Truck, M977
HEMTT Cargo Truck, M978 HEMTT Fuel Truck, Male On Motor- bike, Male On Bike, Patriot Air Defense System (PAC-3), MO- 120RT-61 Mortar, MOWAG Duro (No 3D), MOWAG Eagle (No 3D), MRAP-ATV, MRAP-CAT II Cougar, MRAP-CAT I MaxxPro,
Mule, Navistar 7000 (No 3D), Panther CLV (No 3D), EPP-III Patriot Power Generator, Puma AFV (No 3D), RG-31 Nyala (No 3D), SA-9 Gaskin SAM System, Sheep, Technical Truck, URO VAMTAC (No 3D), VBCI APC (No 3D), VM 90 LSVW (No 3D),
Water Buffalo, ZIL-135 8x8 Truck
Wheels (road) Aircraft Baggage Conveyor, Aircraft Baggage Truck, Aircraft Baggage Wagon, Aircraft Catering Truck, Aircraft Follow Me Car, Aircraft High Loader Dolly, Aircraft Mobile Stairs, Aircraft Tow Tractor 1, Aircraft Tow Tractor 2, Aircraft Towbar, Airport Bus, Ambulance, Auto Rickshaw, BMW 320D Series, BMW 328i Series, BMW M5 Series, BMW X3 Series, BMW X5 Series, Bull- dozer, Bus MBTA, Bus, BV206 SUSV (No 3D), Car Bomb, Chev- rolet Caprice, Chevy Tahoe, Civilian vehicle, Federal Express Truck, Fiat 124, Food Truck, Ford Aircraft Oil Truck, Ford Contour, Fuel Tanker Trailer, G-Wagen (No 3D), GAZ-66 Truck, Honda Accord (Silver), Honda Accord, Jingle Truck, Ladder Truck, M-Gator ATV, M1028 FMTV Cargo Truck, Mercedes M Series, MILCOTTS Silverado (No 3D), Mini Cooper Silver, Nissan Maxima, Paddy Wagon, Police Car (BMW M5), Police Cruiser (Chevy), Police Paddy Wagon, Police Tactical Van, Police Car (Ford), Safir Military Vehicle, Taxicab, Toyota Corolla, Toyota Pickup, Tractor Trailer Cab, Tractor Trailer with Cab, US Postal Truck, Van (Blue), Van (Green), Van (Red), Van (White), Volk- swagen Golf (Black), Volkswagen Golf (White), Volkswagen Passat, Wiesel AWC (No 3D)
GSh-301 Cannon AMX (No 3D), Chengdu J-7 (No 3D), Mirage 2000, Nanchang Q-5 (No 3D), Shenyang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), SU-25 Frogfoot, SU-27 Flanker, Su-37 Flanker, Xian H-6 Badger (No 3D)
AK-47 Afghan Police Officer, Afghan Soldier, African Insurgent, DI AK- 47, DI Lasing (CIS), Insurgent, Iranian Soldier, ISIS Fighter, Kurdish Fighter, Libyan Police Officer, Libyan Soldier, Mideast Combatant, Pakistani Police Officer, Pakistani Soldier, Russian Rebels, Somali Police Officer, Somali Soldier, Sudanese Police Officer, Sudanese Soldier, Syrian Police Officer, Syrian Soldier, Taliban, Ugandan Police Officer, Ugandan Soldier
AT4 Chilean AT4, US Army AT4
Throw Grenades Afghan Police Officer, Afghan Soldier, African Insurgent, Border Patrol Agent, Brazilian Soldier, Chilean AT4, Chilean IMI Galil, Chilean M16, Chilean M240, Chilean M249, Chilean M4, Chilean M60, Colombian Police Officer, Colombian Soldier, DI AK-47, DI Lasing (CIS), DI Lasing (US), DI RPG, DI SMAW And
Rifle, European Soldier, Ghillie Suit Soldier, Insurgent, Iranian Soldier, Iraqi Police Officer, Iraqi Soldier, ISIS Fighter, Kurdish Fighter, Libyan Police Officer, Libyan Soldier, Mideast Combatant, Mideast Combatant with RPG, Pakistani Police Officer, Pakistani Soldier, Police Officer, Russian Rebels, Sergeant M16, Somali Police Officer, Somali Soldier, Sudanese Police Officer, Sudanese Soldier, Suspect, Syrian Police Officer, Syrian Soldier, Taliban, Ugandan Police Officer, Ugandan Soldier, UK Soldier, US Air Force, US Navy With Binoculars, US Navy, USMC M16, USMC M240, USMC M249, USMC M4, US
Army AT4, US Army Javelin, US Army M16, US Army M240, US Army M249, US Army M4, US Army M60, US Army M9
M16 rifle Border Patrol Agent, Brazilian Soldier, Chilean IMI Galil, Chilean M16-M203, Chilean M16, Chilean M4, Colombian Police Officer, Colombian Soldier, DI Lasing (US), DI SMAW And Rifle, Emergency Medical Technician, European Soldier, Ghillie Suit Soldier, Iraqi Police Officer, Iraqi Soldier, Police Officer, Sergeant M16, Suspect, UK Soldier, US Navy With Binoculars, US Navy, USMC M16-M203, USMC M16, USMC M4, US Army M16- M203, US Army M16, US Army M4, US Army M9
Handheld M240B Machine Gun
Chilean M240, USMC M240, US Army M240
M249 SAW Chilean M249, USMC M249, US Army M249
Handheld M60 Machine Gun
Chilean M60, US Army M60
RPG Launcher DI RPG, , Mideast Combatant with RPG, US Army Javelin Handheld UAV Ababil UAV (No 3D), EMT Aladin (No 3D), EMT Luna (No 3D),
Maveric UAS (No 3D), Mohajer UAV (No 3D), RDE KZO (No 3D),
RQ-11 Raven UAV, RQ-7 Shadow UAV (No 3D), ScanEagle UAV (No 3D)
Section XIV - Appendixes
D-24 VT MAK
Homing Torpedo Capability (Forward Launched)
Human Disaggre- gated Movement
Admiral Grigorovich-class Frigate (No 3D), Agosta 90B-class Submarine (No 3D), AgustaWestland AW101 (No 3D), Ahmad Yani-class Frigate, Akula-class Submarine (No 3D), Albatros- class Fast Attack (No 3D), Aquitaine-class Frigate (No 3D), Arleigh Burke-class Destroyer, Asagiri-class Destroyer (No 3D), Astute-class Submarine (No 3D), Brandenburg-class Frigate (No 3D), Bremen-class Frigate (No 3D), Challenger-class Submarine (No 3D), De Zeven Provincien Class Frigate (No 3D), Delhi-class Destroyer (No 3D), Delta III-class Submarine (No 3D), Delta IV- class Submarine (No 3D), Dolphin-class Submarine (No 3D), Durand de la Penne-class Destroyer (No 3D), F-22P Zulfiquar- class Frigate (No 3D), Fatahillah-class Frigate (No 3D), Flyve- fisken-class Patrol Boat (No 3D), Fridtjof Nansen-class (No 3D), Gepard-class Frigate (No 3D), Gotland-class Submarine (No 3D), Grisha-class Corvette (No 3D), Halifax-class Frigate (No 3D), Harbin SH-5 ASW (No 3D), Hauk-class Fast Attack (No 3D), Iroquois-class Destroyer (No 3D), Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), Kilo-class Submarine (No 3D), Kingston-class Patrol vessel, Kirov-class Guided Missile Cruiser (No 3D), Kolkata-class Destroyer (No 3D), Los Angeles-Class Submarine, Lupo-class Frigate (No 3D), Maestrale-class Frigate (No 3D), Milgem Class Corvette, Moudge-class Frigate (No 3D), Murasame-class Destroyer (No 3D), Neustrashimyy-class Frigate (No 3D), Niteroi-class Frigate (No 3D), Ohio-class Submarine, Oscar-class Submarine (No 3D), Pauk-class Corvette (No 3D), Romeo-class Submarine, Rubis-Class Submarine, RUR-5 ASROC, Sachsen-class Frigate (No 3D), Scorpene-class Subma- rine (No 3D), SH-60 Seahawk, Siera II-class Submarine (No 3D), Sigma 9113-class Frigate, Slava-class Guided Missile Cruiser (No 3D), Sodermanland-class Submarine (No 3D), Song-class Submarine, Sovremennyy-class Destroyer, Steregushchiy-class Frigate (No 3D), Trafalgar-class Submarine (No 3D), Triomphant- Class Submarine (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 093 (Shang-class) Submarine (No 3D), Type 209 Subma- rine (No 3D), Type 212 Submarine (No 3D), Type 42 Destroyer (No 3D), Type 45 Destroyer, Type 23 Frigate, Udaloy-class Destroyer, Ula-class Submarine (No 3D), Vanguard-class Subma- rine (No 3D), Victor II-class Submarine (No 3D), Victoria-class (No 3D), Victory-class Corvette (No 3D), Walrus-class subma- rine (No 3D), Yuan-class Submarine (No 3D)
COLT Team (CIS), COLT Team (US), DI Plt (CIS), DI Squad (CIS), USMC FT, USMC SQD, US Army LtInf FT, US Army LtInf
SQD, US Army Mech FT A (Javelin), US Army Mech FT B, US Army Mech SQD
Suicide Vest Suicide Bomber
Flee From Explo- sions
Child, Civilian Airport Worker, Civilian (Chem/Bio Behavior), Civilian Female, Civilian Male, Construction Worker, Female Civilian (Crowd Behavior), Male Civilian (Crowd Behavior), Mideast Female, Mideast Male
Human Default Afghan Police Officer, Afghan Soldier, African Insurgent, Border Patrol Agent, Brazilian Soldier, Cameraman, Chicken, Child, Child (Crowd Behavior), Chilean AT4, Chilean IMI Galil, Chilean M16-M203, Chilean M16, Chilean M240, Chilean M249, Chilean M4, Chilean M60, Civilian Airport Worker, Civilian (Chem/Bio Behavior), Civilian Female, Civilian Male, Colombian Police Officer, Colombian Soldier, Construction Worker, DI AK- 47, DI Lasing (CIS), DI Lasing (US), DI RPG, DI SMAW And Rifle, Emergency Medical Technician, European Soldier, Factory Worker, Female Civilian (Crowd Behavior), Female Dancer, Fireman (Extinguisher), Fireman (Hose), Flight Deck Crew, Flight Deck Crewman, Flight Deck Crew (Chock And Chains), Flight Deck Crew (Grounding Cable), Flight Deck Crew (Pallet Handler), Flight Deck Worker, Ghillie Suit Soldier, Insurgent, Iranian Soldier, Iraqi Police Officer, Iraqi Soldier, ISIS Fighter, Kurdish Fighter, Libyan Police Officer, Libyan Soldier, Male Civilian (Crowd Behavior), Man in Wheelchair, Mideast Combatant, Mideast Combatant with RPG, Mideast Female, Mideast Female (Crowd Behavior), Mideast Male, Mideast Male (Crowd Behavior), Pakistani Police Officer, Pakistani Soldier, Police Officer, Russian Rebels, Sergeant M16, Somali Police Officer, Somali Soldier, Sudanese Police Officer, Sudanese Soldier, Suicide Bomber, Suspect, Syrian Police Officer, Syrian Soldier, Taliban, Ugandan Police Officer, Ugandan Soldier, UK Soldier, US Air Force, US Army Medic, US EOD, US Navy With Binocu- lars, US Navy, USMC M16-M203, USMC M16, USMC M240, USMC M249, USMC M4, US Army AT4, US Army Javelin, US Army M16-M203, US Army M16, US Army M240, US Army M249, US Army M4, US Army M60, US Army M9, Western Teen
Section XIV - Appendixes
D-26 VT MAK
IFF Transponder A-10 Thunderbolt, A-4 Skyhawk (No 3D), AgustaWestland AW101 (No 3D), AgustaWestland AW109 (No 3D), AH-1W SuperCobra, AH-64A Apache, AH-6 Little Bird (No 3D), Airbus 310, Airbus 320 - American Airlines, Airbus 320 - British Airways, Airbus 320 - Lufthansa, Airbus 320 - Singapore Airlines, Airbus 380 (No 3D), Albatros-class Fast Attack (No 3D), AMX (No 3D), Antonov-class (No 3D), AS 332 Super Puma (No 3D), AS 532 Cougar (No 3D), AS 550 Fennec (No 3D), AS-
365 Dauphin (No 3D), AS-565 Panther (No 3D), Asagiri-class Destroyer (No 3D), Astute-class Submarine (No 3D), AT-802 (No 3D), AV-8B Harrier II, B-2 Spirit, BAE CT-155 Hawk (No 3D), Bay-class DLS (No 3D), Bay-class Patrol Boat (No 3D), Beechcraft 36 Bonanza (No 3D), Beechcraft C-12 Super King (No 3D), Beechcraft T-6 (No 3D), Bell 412 (No 3D), Bell 206 JetRanger (No 3D), Bell 406 (No 3D), BN-2 Islander (No 3D), Boeing 707, Boeing 737 British Midland, Boeing 747-400, Boeing 757 (No 3D), Boeing 767 (No 3D), Boeing 777 (No 3D), Boeing 787 (No 3D), Bombardier CL-600 (No 3D), Bombardier DHC-8 (No 3D), Sentinel R1 (No 3D), Bombardier CRJ100 Conrad Air, Bombardier CRJ200 Air France, C-130 Hercules, C- 17 Globemaster III (No 3D), C-5 Galaxy (No 3D), Canadair CT- 114 (No 3D), Cape-class Patrol Boat (No 3D), CASA C-212 Aviocar (No 3D), Cessna 172 Skyhawk, Cessna Citation (No 3D), CH-148 Cyclone (No 3D), CH-149 Cormorant, CH-46E Sea Knight, CH-47 Chinook (No 3D), CH-53E Super Stallion, Chengdu J-7 (No 3D), Cypher VTUAV, Dabur-class Patrol Boat (No 3D), Dassault Atlantic (No 3D), Dassault Mystere-Falcon 20 (No 3D), Dassault Mystere-Falcon 900 (No 3D), Delhi-class Destroyer (No 3D), Dornier DO 228-200 LGW, Dragon Warrior VTUAV, Durand de la Penne-class Destroyer (No 3D), E-2 Hawkeye, E-3 Sentry, EA-6B Prowler, EADS CASA C-295 (No 3D), EC 135 (No 3D), EC 635 (No 3D), EC145 (No 3D), EC665
Eurocopter Tiger (No 3D), EC725 Caracal (No 3D), Echo-class Survey Ship (No 3D), EH101 Merlin (No 3D), Eurofighter Typhoon, F-117A Nighthawk, F-15 Eagle, F-16A Fighting Falcon, F-22P Zulfiquar-class Frigate (No 3D), F-22 Raptor (No 3D), F-35 Lightning II, Fatahillah-class Frigate (No 3D), F/A-18 Hornet, Gulfstream G550 (No 3D), Halifax-class Frigate (No 3D), Hamina-class Fast Attack (No 3D), Harbin SH-5 ASW (No 3D), Hauk-class Fast Attack (No 3D), HH-65 Dolphin (No 3D), Horizon-class Destroyer (No 3D), Hunt-class Minehunter (No 3D), IAI 1124 Sea Scan (No 3D), Il-76 Candid (No 3D), Iroquois- class Destroyer (No 3D), Island-class Patrol Vessel (No 3D), KA- 50 Hokum, KC-135 Stratotanker, KCR-40 Clurit-class Fast Attack (No 3D), KD-III-class Destroyer (No 3D), Kolkata-class Destroyer (No 3D), L 14 Albion (No 3D), Lockheed L-1011 (No 3D), LPH01 Ocean (No 3D), MD 500 (No 3D), MH-47 Chinook
(No 3D), MH-60L Black Hawk DAP (No 3D), MH-60 Black Hawk, MH-6 Little Bird (No 3D), Mi-17 Hip (No 3D)
IFF Transponder (continued)
Mi-24 Hind, Mi-28 Havoc, Mi-2 Hoplite, MiG-27 Flogger, MiG-29 Fulcrum, Milgem Class Corvette, Mirage 2000, Mirage F1, Murasame-class Destroyer (No 3D), Nanchang Q-5 (No 3D), NH90-N1 (No 3D), Nimitz-class Carrier, OH-58 Kiowa, P-3 Orion, RAH-66 Comanche, River-class Patrol Vessel (No 3D), SA 330 Puma (No 3D), SA 342 Gazelle (No 3D), Saar 4-class Missile Boat (No 3D), Saar 4.5-class Missile Boat (No 3D), Saar 5-class Corvette (No 3D), SH-3 Sea King (No 3D), SH-60 Seahawk, Shenyang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), Sovremennyy-class Destroyer, Space Shuttle, SU-25 Frogfoot, SU-27 Flanker, Su-37 Flanker, Tornado ADV (No 3D), Tu-160 Blackjack (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 42 Destroyer (No 3D), Type 45 Destroyer, Type 22 Frigate (No 3D), Type 23 Frigate, Udaloy- class Destroyer, UH-1N Twin Huey (No 3D), UH-60 Blackhawk, UH-72 Lakota (No 3D), Ultralight Trike, V-22 Osprey (No 3D), Victory-class Corvette (No 3D), Westland Lynx (No 3D), WS-61 Sea King (No 3D), Xian H-6 Badger (No 3D), Xian JH-7 (No 3D)
IR Sensor AgustaWestland AW101 (No 3D), AgustaWestland AW109 (No 3D), AH-1W SuperCobra, AH-64A Apache, AH-6 Little Bird (No 3D), Antonov-class (No 3D), Arleigh Burke-class Destroyer, AS 332 Super Puma (No 3D), AS 532 Cougar (No 3D), AS 550 Fennec (No 3D), AS-365 Dauphin (No 3D), AS-565 Panther (No 3D), Bell 412 (No 3D), Bell 206 JetRanger (No 3D), Bell 406 (No 3D), CH-148 Cyclone (No 3D), CH-149 Cormorant, CH-46E Sea Knight, CH-47 Chinook (No 3D), CH-53E Super Stallion, Dabur- class Patrol Boat (No 3D), EC 135 (No 3D), EC 635 (No 3D), EC145 (No 3D), EC665 Eurocopter Tiger (No 3D), EC725 Caracal (No 3D), Echo-class Survey Ship (No 3D), EH101 Merlin (No 3D), Hermes 450 (No 3D), HH-65 Dolphin (No 3D), HMMWV with Avenger, Holland Class OPV (No 3D), Il-76 Candid (No 3D), Island-class Patrol Vessel (No 3D), KA-50 Hokum, Kirov-class Guided Missile Cruiser (No 3D), Maveric UAS (No 3D), MD 500 (No 3D), MH-47 Chinook (No 3D), MH-
60L Black Hawk DAP (No 3D), MH-60 Black Hawk, MH-6 Little Bird (No 3D), Mi-17 Hip (No 3D), Mi-24 Hind, Mi-28 Havoc, Mi- 2 Hoplite, Mistral Class AAS (No 3D), MQ-4C Triton, MQ-8B Fire Scout, MQ-9 Reaper UAV, NH90-N1 (No 3D), OH-58 Kiowa, MQ-1 Predator, RAH-66 Comanche, RDE KZO (No 3D), River-class Patrol Vessel (No 3D), RQ-11 Raven UAV, RQ-4 Global Hawk UAV, RQ-7 Shadow UAV (No 3D), SA 330 Puma (No 3D), SA 342 Gazelle (No 3D), SAGEM Sperwer (No 3D), Sandown-class Minehunter (No 3D), ScanEagle UAV (No 3D), SH-3 Sea King (No 3D), SH-60 Seahawk, Slava-class Guided Missile Cruiser (No 3D), Type 42 Destroyer (No 3D), UH-1N Twin Huey (No 3D), UH-60 Blackhawk, UH-72 Lakota (No 3D), V-22 Osprey (No 3D), Westland Lynx (No 3D), WS-61 Sea King (No 3D)
Laser Designator DI Lasing (CIS), DI Lasing (US)
Section XIV - Appendixes
D-28 VT MAK
Hydra 70 APKWS Launcher
Laser Guided Hell- fire Missile Launcher
Laser Guided Missile Dynamics
MQ-8B Fire Scout
AH-1W SuperCobra, AH-64A Apache, AH-6 Little Bird (No 3D), EC665 Eurocopter Tiger (No 3D), MH-60L Black Hawk DAP (No 3D), MH-60 Black Hawk, MQ-9 Reaper UAV, NH90-N1 (No 3D),
RAH-66 Comanche
Hydra-70, Laser Guided Hellfire Missile
Default Armor Afghan Police Officer, Afghan Soldier, African Insurgent, Border Patrol Agent, Brazilian Soldier, Cameraman, Chicken, Child, Child (Crowd Behavior), Child (Injured), Chilean AT4, Chilean IMI Galil, Chilean M16-M203, Chilean M16, Chilean M240, Chilean M249, Chilean M4, Chilean M60, Civilian Airport Worker, Civilian (Chem/Bio Behavior), Civilian Female, Civilian Male, Colombian Police Officer, Colombian Soldier, Construction Worker, Cow, DI AK-47, DI Lasing (CIS), DI Lasing (US), DI RPG, DI SMAW And Rifle, Emergency Medical Technician, Euro- pean Soldier, Factory Worker, Female Civilian (Crowd Behavior), Female Dancer, Fireman (Extinguisher), Fireman (Hose), Flight Deck Crew, Flight Deck Crewman, Flight Deck Crew (Chock And Chains), Flight Deck Crew (Grounding Cable), Flight Deck Crew (Pallet Handler), Flight Deck Worker, Ghillie Suit Soldier, Insurgent, Iranian Soldier, Iraqi Police Officer, Iraqi Soldier, ISIS Fighter, Kurdish Fighter, Libyan Police Officer, Libyan Soldier, Male Civilian (Crowd Behavior), Man in Wheelchair, Mideast Combatant, Mideast Combatant with RPG, Mideast Female, Mideast Female (Crowd Behavior), Mideast Male, Mideast Male (Crowd Behavior), Pakistani Police Officer, Pakistani Soldier, Police Officer, Russian Rebels, Sergeant M16, Somali Police Officer, Somali Soldier, Sudanese Police Officer, Sudanese Soldier, Suicide Bomber, Suspect, Syrian Police Officer, Syrian Soldier, Taliban, Ugandan Police Officer, Ugandan Soldier, UK Soldier, US Air Force, US Army Medic, US EOD, US Navy With Binoculars, US Navy, USMC M16-M203, USMC M16, USMC M240, USMC M249, USMC M4, US Army AT4, US Army
Javelin, US Army M16-M203, US Army M16, US Army M240, US Army M249, US Army M4, US Army M60, US Army M9, Western Teen
Lifeform Suppres- sion
Limit Entity Exis- tence
M1A2 Main Gun and MGs
M2HB Machine Gun
Afghan Police Officer, Afghan Soldier, African Insurgent, Border Patrol Agent, Brazilian Soldier, Cameraman, Child, Child (Crowd Behavior), Child (Injured), Chilean AT4, Chilean IMI Galil, Chilean M16-M203, Chilean M16, Chilean M240, Chilean M249, Chilean M4, Chilean M60, Civilian Airport Worker, Civilian (Chem/Bio Behavior), Civilian Female, Civilian Male, Colombian Police Officer, Colombian Soldier, Construction Worker, DI AK- 47, DI Lasing (CIS), DI Lasing (US), DI RPG, DI SMAW And Rifle, Emergency Medical Technician, European Soldier, Factory Worker, Female Civilian (Crowd Behavior), Female Dancer, Fireman (Extinguisher), Fireman (Hose), Flight Deck Crew, Flight Deck Crewman, Flight Deck Crew (Chock And Chains), Flight Deck Crew (Grounding Cable), Flight Deck Crew (Pallet Handler), Flight Deck Worker, Ghillie Suit Soldier, Insurgent, Iranian Soldier, Iraqi Police Officer, Iraqi Soldier, ISIS Fighter, Kurdish Fighter, Libyan Police Officer, Libyan Soldier, Male Civilian (Crowd Behavior), Man in Wheelchair, Mideast Combatant, Mideast Combatant with RPG, Mideast Female, Mideast Female (Crowd Behavior), Mideast Male, Mideast Male (Crowd Behavior), Pakistani Police Officer, Pakistani Soldier, Police Officer, Russian Rebels, Sergeant M16, Somali Police Officer, Somali Soldier, Sudanese Police Officer, Sudanese Soldier, Suicide Bomber, Suspect, Syrian Police Officer, Syrian Soldier, Taliban, Ugandan Police Officer, Ugandan Soldier, UK Soldier, US Air Force, US Army Medic, US EOD, US Navy With Binocu- lars, US Navy, USMC M16-M203, USMC M16, USMC M240, USMC M249, USMC M4, US Army AT4, US Army Javelin, US Army M16-M203, US Army M16, US Army M240, US Army M249, US Army M4, US Army M60, US Army M9, Western Teen
CIS Chaff, CIS Flare, Mk-46 MOD 5 Torpedo, Mk-48 ADCAP Torpedo, RUR-5 ASROC, US Chaff, US Flare
M1A2 Abrams MBT
2S19 Msta-S (No 3D), Achzarit APC (No 3D), AMX-10RC (No
3D), AMX-30D (No 3D), Aravis MRAP (No 3D), ASTROS II
MLRS (No 3D), Auverland A4 AVL (No 3D), Badger AEV (No 3D), Bergepanzer 2 ARV (No 3D), BTR-60 APC, Buffel ARV (No 3D), DNG/DCL (No 3D), ERC 90 Sagaie (No 3D), Fenneck, LCS
Freedom Class (No 3D), GTK Boxer APC (No 3D), HMMWV with M2, LCS Independence Class (No 3D), Leopard 2 Tank, LIV (SO) Serval (No 3D), M1126 Stryker ICV, M113 APC, MT-LB APC,
Namer APC (No 3D), PLZ-45 Howitzer (No 3D), Rigid-Hulled Inflatable Boat, Taurus ARV (No 3D), Technical Truck, Type 85 (YW 531H) APC (No 3D), Type 10 MBT (No 3D), Type 90 Kyu-
maru MBT (No 3D), National Security Cutter, VAB APC, VBCI APC (No 3D), Marine Protector Class Patrol Boat, WZ551 APC (No 3D)
Section XIV - Appendixes
D-30 VT MAK
M203 Grenade Launcher
Chilean M16-M203, USMC M16-M203, US Army M16-M203
M230 Chain Gun AH-1W SuperCobra, AH-64A Apache, AH-6 Little Bird (No 3D), MH-60L Black Hawk DAP (No 3D), RAH-66 Comanche, West- land Lynx (No 3D)
M240 Machine Gun
M250 smoke grenade launcher
M252 81mm
mortar
M270 MLRS
Launcher
M284 155mm
Cannon
M60 Machine Gun
AAVC7A1 Landing Vehicle, Arjun MBT (No 3D), AS 550 Fennec (No 3D), ASCOD Ulan AIFV (No 3D), ATF Dingo (No 3D), Bison APC (No 3D), BTR-80 APC, BTR-90, C1 Ariete MBT (No 3D),
Cadillac Gage Commando V-150 (No 3D), Centauro B1 (No 3D), Cougar FSV, CV9035 AFV, Dardo IFV (No 3D), EE-9 Cascavel (No 3D), Freccia IFV (No 3D), Fuchs APC (No 3D), FV4034
Challenger 2 MBT (No 3D), FV432 APC (No 3D), Grizzly APC (No 3D), HH-65 Dolphin (No 3D), Husky ARV (No 3D), Iveco LMV (No 3D), Jackal MWMIK (No 3D), LAPV Enok (No 3D), LAV III APC, LIV (SO) Serval (No 3D), Mamba APC (No 3D), MBT 2000 (No 3D), MH-47 Chinook (No 3D), MOWAG Duro (No 3D), MOWAG Eagle (No 3D), MRAP-ATV, MRAP-CAT II Cougar,
MRAP-CAT I MaxxPro, Panhard AML-245 (No 3D), Panhard M3 APC (No 3D), Panzerhaubitze 2000 Howitzer, Patria AMV (No 3D), Pegaso 3046 APC (No 3D), PT-91 Twardy MBT (No 3D), Puma AFV (No 3D), RG-31 Nyala (No 3D), T-84 MBT (No 3D), T90A MBT (No 3D), Type 99 MBT (No 3D), V-22 Osprey (No 3D), VM 90 LSVW (No 3D), WZ551 APC (No 3D)
Achzarit APC (No 3D), AMX-10RC (No 3D), Arjun MBT (No 3D),
Badger AEV (No 3D), Bandvagn 206 (No 3D), Bergepanzer 2 ARV (No 3D), Buffel ARV (No 3D), CV9035 AFV, EE-9 Cascavel (No 3D), ERC 90 Sagaie (No 3D), Fuchs APC (No 3D), M1A2
Abrams MBT, Merkava III MBT (No 3D), Merkava IV MBT (No 3D), Namer APC (No 3D), Puma AFV (No 3D), Puma CEV (No 3D), Taurus ARV (No 3D), Type 10 MBT (No 3D)
M252 Mortar
ASTROS II MLRS (No 3D), M270 MLRS, M993 MLRS
2S19 Msta-S (No 3D), AS-90 Artillery, AUF1 155mm Howitzer (No 3D), CAESAR SP Howitzer, L-118 Howitzer (No 3D), LG1 Howitzer (No 3D), M-71 Howitzer (No 3D), M109 Howitzer, M777 Howitzer (No 3D), Panzerhaubitze 2000 Howitzer, PLZ-45 Howitzer (No 3D), URO VAMTAC (No 3D)
CH-148 Cyclone (No 3D), CH-47 Chinook (No 3D), MH-60 Black Hawk, SH-3 Sea King (No 3D)
M61 Vulcan AMX (No 3D), F-15 Eagle, F-16A Fighting Falcon, F-22 Raptor (No 3D), F/A-18 Hornet
MAD Sensor CH-46E Sea Knight, Dassault Atlantic (No 3D), Harbin SH-5 ASW (No 3D), P-3 Orion, SH-60 Seahawk
Missile Default Armor
Guided Missile Dynamics
AA-11 Archer Missile, AA-8 Aphid Missile, AGM-65 Maverick Missile, AIM-9 Sidewinder Missile, AS-12 Kegler Missile, AS-14 Kedge Missile, AS-7 Kerry Missile, AT-6 Spiral Missile, BGM-71 TOW Missile, Exocet Cruise Missile, FIM-92 Stinger Missile, Hellfire Missile, Hydra-70, Laser Guided Hellfire Missile, M39 Missile, MIM 104C PAC-3 Patriot Missile, Mistral SAM Missile (No 3D), RUR-5 ASROC, SA-9 Missile, Scud-B Missile, SM-2 Standard Missile, SS-24 Scalpel Missile, SS-24 Scalpel Stage
AA-11 Archer Missile, AA-8 Aphid Missile, AGM-65 Maverick Missile, AIM-9 Sidewinder Missile, AS-12 Kegler Missile, AS-14 Kedge Missile, AS-7 Kerry Missile, AT-6 Spiral Missile, BGM-71 TOW Missile, Exocet Cruise Missile, FIM-92 Stinger Missile, Hellfire Missile, Hydra-70, Laser Guided Hellfire Missile, MIM 104C PAC-3 Patriot Missile, Mistral SAM Missile (No 3D), RUR- 5 ASROC, SA-9 Missile, SM-2 Standard Missile
Missile Warhead 76mm Shell, Ababil UAV (No 3D), Agosta 90B-class Submarine (No 3D), Delta III-class Submarine (No 3D), Delta IV-class Submarine (No 3D), Exocet Cruise Missile, M107 155mm, M26 Rocket, M374A2 81mm, M433, M583A1, M651, M713,
M715, M716, Oscar-class Submarine (No 3D), Rubis-Class Submarine, SM-2 Standard Missile, Triomphant-Class Submarine (No 3D), Type 094 (Jin-class) Submarine (No 3D), Yuan-class Submarine (No 3D)
MK 45 Naval Gun Arleigh Burke-class Destroyer, Bay-class DLS (No 3D), Dabur- class Patrol Boat (No 3D), De Zeven Provincien Class Frigate (No 3D), Delhi-class Destroyer (No 3D), Durand de la Penne-class Destroyer (No 3D), Echo-class Survey Ship (No 3D), Guided Missile Destroyer, Halifax-class Frigate (No 3D), Hauk-class Fast Attack (No 3D), Hunt-class Minehunter (No 3D), Iroquois-class Destroyer (No 3D), Island-class Patrol Vessel (No 3D), L-class Frigate (No 3D), Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), KD-III-class Destroyer (No 3D), Kingston-class Patrol vessel, L 14 Albion (No 3D), Legend Class (WMSL), LPH01 Ocean (No 3D), Milgem Class Corvette, Oksoy-class Minehunter (No 3D), River-class Patrol Vessel (No 3D), Saar 4- class Missile Boat (No 3D), Saar 4.5-class Missile Boat (No 3D), Skjold-class Patrol (No 3D), Sovremennyy-class Destroyer, Steregushchiy-class Frigate (No 3D), Super Dvora Mark II (No 3D), Tiger-class Fast Attack Craft (No 3D), Type 42 Destroyer (No 3D), Type 45 Destroyer, Type 22 Frigate (No 3D), Type 23 Frigate, Udaloy-class Destroyer, Hamilton Class Cutter WHEC
Naval Depth Charge Deploy- ment
B-2 Spirit, Dassault Atlantic (No 3D), Harbin SH-5 ASW (No 3D), P-3 Orion
Section XIV - Appendixes
D-32 VT MAK
Naval Mine Deployment
Naval Mine Dynamics
Naval Mine Explo- sive Device
Naval Mine Sweep
Other Explosive Device
B-2 Spirit, Braunschweig-class Corvette (No 3D), Dassault Atlantic (No 3D), Durand de la Penne-class Destroyer (No 3D), Frankenthal-class Minehunter (No 3D), Gaeta-class Minehunter, Gotland-class Submarine (No 3D), Grisha-class Corvette (No 3D), Halifax-class Frigate (No 3D), Hamina-class Fast Attack (No 3D), Harbin SH-5 ASW (No 3D), Horizon-class Destroyer (No 3D), Hunt-class Minehunter (No 3D), Kilo-class Submarine (No 3D), Milgem Class Corvette, Osprey-class Mine CMS (No 3D), P- 3 Orion, Runnymede-class Landing Craft Utility 2000 (No 3D), Sandown-class Minehunter (No 3D), Skjold-class Patrol (No 3D), Sovremennyy-class Destroyer, Tiger-class Fast Attack Craft (No 3D), Type 212 Submarine (No 3D), Type 42 Destroyer (No 3D), Type 45 Destroyer, Type 22 Frigate (No 3D), Type 23 Frigate
Naval Mine, Quickstrike Mk 65, Sea Lance ASW Naval Mine, Quickstrike Mk 65, Sea Lance ASW
Alta-class Minehunter (No 3D), Gaeta-class Minehunter, Hunt- class Minehunter (No 3D), Kingston-class Patrol vessel, Osprey- class Mine CMS (No 3D), Oksoy-class Minehunter (No 3D), Sandown-class Minehunter (No 3D), Tiger-class Fast Attack Craft (No 3D)
Passive RADAR Sensor
Passive SONAR Sensor
Patriot Missile Launcher
Pedestrian Crowd Movement
Pedestrian Traffic Generator
Ahmad Yani-class Frigate, Aquitaine-class Frigate (No 3D), Arleigh Burke-class Destroyer, Bay-class Patrol Boat (No 3D), Brandenburg-class Frigate (No 3D), Braunschweig-class Corvette (No 3D), Bremen-class Frigate (No 3D), Cape-class Patrol Boat (No 3D), Dabur-class Patrol Boat (No 3D), De Zeven Provincien Class Frigate (No 3D), Echo-class Survey Ship (No 3D), Eridan- class Minehunter (No 3D), Floreal-class Frigate (No 3D), Flyve- fisken-class Patrol Boat (No 3D), LCS Freedom Class (No 3D), Fridtjof Nansen-class (No 3D), Holland Class OPV (No 3D), Hunt- class Minehunter (No 3D), LCS Independence Class (No 3D), Iroquois-class Destroyer (No 3D), Island-class Patrol Vessel (No 3D), Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), KD-III-class Destroyer (No 3D), Khareff-class Corvette (No 3D), Kirov-class Guided Missile Cruiser (No 3D), La Fayette-class Frigate (No 3D), Lupo-class Frigate (No 3D), M270 MLRS, Maes- trale-class Frigate (No 3D), Mistral Class AAS (No 3D), Niteroi- class Frigate (No 3D), Rapier SAM (No 3D), River-class Patrol Vessel (No 3D), Rubis-Class Submarine, SA-15 Gauntlet SAM, SA-19 Grison, SA-6 Gainful SAM, SA-9 Gaskin SAM System, Sachsen-class Frigate (No 3D), Sandown-class Minehunter (No 3D), Scorpene-class Submarine (No 3D), Sigma 9113-class Frigate, Slava-class Guided Missile Cruiser (No 3D), Super Tanker, Triomphant-Class Submarine (No 3D), Type 209 Subma- rine (No 3D), Type 23 Frigate, Vanguard-class Submarine (No 3D), Victoria-class (No 3D), Marine Protector Class Patrol Boat
Akula-class Submarine (No 3D), Aquitaine-class Frigate (No 3D), Brandenburg-class Frigate (No 3D), De Zeven Provincien Class Frigate (No 3D), Eridan-class Minehunter (No 3D), Fridtjof Nansen-class (No 3D), L-class Frigate (No 3D), Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), Kilo-class Submarine (No 3D), La Fayette-class Frigate (No 3D), Legend Class (WMSL), Niteroi-class Frigate (No 3D), Oksoy-class Mine- hunter (No 3D), Sonobuoy (Passive), Steregushchiy-class Frigate (No 3D), National Security Cutter, Hamilton Class Cutter WHEC, Victor II-class Submarine (No 3D)
M901 Patriot Launcher, Patriot Air Defense System (PAC-3)
Civilian Crowd (Large), Civilian Crowd (Medium), Civilian Crowd (Small), Civilian Crowd
Civilian Crowd (Large), Civilian Crowd (Medium), Civilian Crowd (Small), Civilian Crowd, Pedestrian Area
Section XIV - Appendixes
D-34 VT MAK
Periscope Agosta 90B-class Submarine (No 3D), Akula-class Submarine (No 3D), Astute-class Submarine (No 3D), Challenger-class Submarine (No 3D), Delta III-class Submarine (No 3D), Delta IV- class Submarine (No 3D), Dolphin-class Submarine (No 3D), Gotland-class Submarine (No 3D), Kilo-class Submarine (No 3D), Los Angeles-Class Submarine, Ohio-class Submarine, Oscar- class Submarine (No 3D), Romeo-class Submarine, Rubis-Class Submarine, Scorpene-class Submarine (No 3D), Siera II-class Submarine (No 3D), Sodermanland-class Submarine (No 3D), Song-class Submarine, Trafalgar-class Submarine (No 3D), Triomphant-Class Submarine (No 3D), Type 093 (Shang-class) Submarine (No 3D), Type 094 (Jin-class) Submarine (No 3D), Type 209 Submarine (No 3D), Type 212 Submarine (No 3D), Ula-class Submarine (No 3D), Vanguard-class Submarine (No 3D), Victor II-class Submarine (No 3D), Victoria-class (No 3D), Walrus-class submarine (No 3D), Yuan-class Submarine (No 3D)
Rotary Wing Attack
Rotary Wing Default Armor
AH-1W SuperCobra, AH-64A Apache, AS 550 Fennec (No 3D), AS-365 Dauphin (No 3D), AS-565 Panther (No 3D), EC665 Eurocopter Tiger (No 3D), EC725 Caracal (No 3D), HH-65 Dolphin (No 3D), KA-50 Hokum, Mi-24 Hind, Mi-28 Havoc, RAH-66 Comanche, SA 342 Gazelle (No 3D)
AgustaWestland AW101 (No 3D), AgustaWestland AW109 (No 3D), AH-1W SuperCobra, AH-64A Apache, AH-6 Little Bird (No 3D), AirMule, Antonov-class (No 3D), AS 332 Super Puma (No 3D), AS 532 Cougar (No 3D), AS 550 Fennec (No 3D), AS-365
Dauphin (No 3D), AS-565 Panther (No 3D), Bell 412 (No 3D), Bell 206 JetRanger (No 3D), Bell 406 (No 3D), CH-148 Cyclone (No 3D), CH-149 Cormorant, CH-46E Sea Knight, CH-47 Chinook (No 3D), CH-53E Super Stallion, Cypher VTUAV, DJI S1000, Dragon Warrior VTUAV, EC 135 (No 3D), EC 635 (No
3D), EC145 (No 3D), EC665 Eurocopter Tiger (No 3D), EC725 Caracal (No 3D), EH101 Merlin (No 3D), HH-65 Dolphin (No 3D), Il-76 Candid (No 3D), KA-50 Hokum, MD 500 (No 3D), MH-47
Chinook (No 3D), MH-60L Black Hawk DAP (No 3D), MH-60 Black Hawk, MH-6 Little Bird (No 3D), Mi-17 Hip (No 3D), Mi-24 Hind, Mi-28 Havoc, Mi-2 Hoplite, MQ-8B Fire Scout, NH90-N1 (No 3D), OH-58 Kiowa, Quadcopter, RAH-66 Comanche, SA 330 Puma (No 3D), SA 342 Gazelle (No 3D), SH-3 Sea King (No 3D), SH-60 Seahawk, UH-1N Twin Huey (No 3D), UH-60 Black- hawk, UH-72 Lakota (No 3D), V-22 Osprey (No 3D), Westland Lynx (No 3D), WS-61 Sea King (No 3D)
Cargo AgustaWestland AW101 (No 3D), AgustaWestland AW109 (No 3D), Antonov-class (No 3D), AS 332 Super Puma (No 3D), AS 532 Cougar (No 3D), CH-148 Cyclone (No 3D), CH-47 Chinook (No 3D), CH-53E Super Stallion, EH101 Merlin (No 3D), Il-76 Candid (No 3D), MH-47 Chinook (No 3D), SA 330 Puma (No 3D), SH-3 Sea King (No 3D), V-22 Osprey (No 3D), Westland Lynx (No 3D), WS-61 Sea King (No 3D)
Quadcopter Heavy Lift
AirMule
Quadcopter DJI S1000, Quadcopter
Dipping SONAR Sensor
CH-46E Sea Knight, NH90-N1 (No 3D), SH-3 Sea King (No 3D),
SH-60 Seahawk
Utility AH-6 Little Bird (No 3D), Bell 412 (No 3D), Bell 206 JetRanger (No 3D), Bell 406 (No 3D), CH-149 Cormorant, CH-46E Sea Knight, EC 135 (No 3D), EC 635 (No 3D), EC145 (No 3D), MD 500 (No 3D), MH-60L Black Hawk DAP (No 3D), MH-60 Black
Hawk, MH-6 Little Bird (No 3D), Mi-17 Hip (No 3D), Mi-2 Hoplite, MQ-8B Fire Scout, NH90-N1 (No 3D), OH-58 Kiowa, SH-60 Seahawk, UH-1N Twin Huey (No 3D), UH-60 Blackhawk, UH-72 Lakota (No 3D)
VTUAV Cypher VTUAV, Dragon Warrior VTUAV
SA-9 SAM Missile Launcher
Scripted Move- ment
Rapier SAM (No 3D), SA-15 Gauntlet SAM, SA-19 Grison, SA-6 Gainful SAM, SA-9 Gaskin SAM System
M39 Missile, Scud-B Missile, SS-24 Scalpel Missile, SS-24 Scalpel Stage
Small boat Albatros-class Fast Attack (No 3D), Bay-class Patrol Boat (No 3D), Cape-class Patrol Boat (No 3D), Dabur-class Patrol Boat (No 3D), Echo-class Survey Ship (No 3D), Fleet-class USV (No 3D), Grisha-class Corvette (No 3D), Hamina-class Fast Attack (No 3D), Hauk-class Fast Attack (No 3D), Holland Class OPV (No 3D), Island-class Patrol Vessel (No 3D), Jacinto-class Corvette (No 3D), Jet Ski, KAAN 19 Class Fast Patrol Craft, KCR-40 Clurit-class Fast Attack (No 3D), Nanuchka III-class (No 3D), Pauk-class Corvette (No 3D), Rigid-Hulled Inflatable Boat, Rigid- Hulled Inflatable Boat - Civilian, River-class Patrol Vessel (No 3D), Saar 4-class Missile Boat (No 3D), Saar 4.5-class Missile Boat (No 3D), Saar 5-class Corvette (No 3D), Sailboat, Skiff (Green), Skiff, Skjold-class Patrol (No 3D), Speedboat, Steregus- hchiy-class Frigate (No 3D), Super Dvora Mark II (No 3D), Tarantul-class Corvette (No 3D), Tiara 3900 Yacht, Tiger-class Fast Attack Craft (No 3D)
Bomb Dynamics CBU-105 SFW, GBU-31A JDAM, KAB-500N Bomb
Section XIV - Appendixes
D-36 VT MAK
SONAR Sensor Agosta 90B-class Submarine (No 3D), Ahmad Yani-class Frigate, Aircraft Carrier, Akula-class Submarine (No 3D), Alta-class Mine- hunter (No 3D), AN/BLQ-11 UUV (No 3D), Aquitaine-class Frigate (No 3D), Arleigh Burke-class Destroyer, Asagiri-class Destroyer (No 3D), Astute-class Submarine (No 3D), Bay-class DLS (No 3D), Brandenburg-class Frigate (No 3D), Bremen-class Frigate (No 3D), CH-46E Sea Knight, Challenger-class Submarine (No 3D), Charles De Gaulle R91 (No 3D), De Zeven Provincien Class Frigate (No 3D), Delhi-class Destroyer (No 3D), Delta III- class Submarine (No 3D), Delta IV-class Submarine (No 3D), Dolphin-class Submarine (No 3D), Durand de la Penne-class Destroyer (No 3D), Eridan-class Minehunter (No 3D), Fatahillah- class Frigate (No 3D), Flyvefisken-class Patrol Boat (No 3D), Frankenthal-class Minehunter (No 3D), Fridtjof Nansen-class (No 3D), Gaeta-class Minehunter, Gepard-class Frigate (No 3D), Gotland-class Submarine (No 3D), Grisha-class Corvette (No 3D), Guided Missile Destroyer, Krivak-class Guided Missile Frigate, Halifax-class Frigate (No 3D), Hamina-class Fast Attack (No 3D), Horizon-class Destroyer (No 3D), Hunt-class Minehu- nter (No 3D), Iroquois-class Destroyer (No 3D), L-class Frigate (No 3D), Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), KD-III-class Destroyer (No 3D), Kilo-class Submarine (No 3D), Kingston-class Patrol vessel, Kirov-class Guided Missile Cruiser (No 3D), Kolkata-class Destroyer (No 3D), Kuznetsov- class (No 3D), L 14 Albion (No 3D), La Fayette-class Frigate (No 3D), Legend Class (WMSL), Los Angeles-Class Submarine, LPH01 Ocean (No 3D), Harpers Ferry-class LSD, Milgem Class Corvette, Osprey-class Mine CMS (No 3D), Mistral Class AAS (No 3D), Mk-46 MOD 5 Torpedo, Mk-48 ADCAP Torpedo, Murasame-class Destroyer (No 3D), Neustrashimyy-class Frigate (No 3D), NH90-N1 (No 3D), Nimitz-class Carrier, Niteroi-class Frigate (No 3D), Ohio-class Submarine, Oksoy-class Minehunter (No 3D), Oscar-class Submarine (No 3D), Pauk-class Corvette (No 3D), REMUS UUV, Romeo-class Submarine, Rubis-Class Submarine, Saar 5-class Corvette (No 3D), Sachsen-class Frigate (No 3D), Sandown-class Minehunter (No 3D), Scorpene- class Submarine (No 3D), SH-3 Sea King (No 3D), SH-60 Seahawk, Siera II-class Submarine (No 3D), Sigma 9113-class Frigate, Skjold-class Patrol (No 3D), Slava-class Guided Missile Cruiser (No 3D), Sodermanland-class Submarine (No 3D), Song- class Submarine, Sonobuoy (Passive), Sovremennyy-class Destroyer, Steregushchiy-class Frigate (No 3D), Trafalgar-class Submarine (No 3D), Triomphant-Class Submarine (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 093 (Shang-class) Submarine (No 3D), Type 094 (Jin-class) Submarine (No 3D), Type 209 Submarine (No 3D), Type 212 Submarine (No 3D), Type 42 Destroyer (No 3D), Type 45 Destroyer, Type 22 Frigate (No 3D), Type 23 Frigate, Udaloy-class Destroyer, Ula- class Submarine (No 3D), National Security Cutter, Hamilton Class Cutter WHEC, Victor II-class Submarine (No 3D), Victoria- class (No 3D), Victory-class Corvette (No 3D), Marine Protector Class Patrol Boat
SONAR Sensor (continued)
Sonobuoy Deployer
Yuan-class Submarine (No 3D)
Bay-class DLS (No 3D), Bay-class Patrol Boat (No 3D), Cape- class Patrol Boat (No 3D), Dabur-class Patrol Boat (No 3D), Dassault Atlantic (No 3D), Echo-class Survey Ship (No 3D), F- 22P Zulfiquar-class Frigate (No 3D), Fatahillah-class Frigate (No 3D), Halifax-class Frigate (No 3D), Harbin SH-5 ASW (No 3D), Horizon-class Destroyer (No 3D), Iroquois-class Destroyer (No 3D), Island-class Patrol Vessel (No 3D), L 14 Albion (No 3D), LPH01 Ocean (No 3D), Milgem Class Corvette, P-3 Orion, River- class Patrol Vessel (No 3D), Tiger-class Fast Attack Craft (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 45 Destroyer, Type 22 Frigate (No 3D), Victory-class Corvette (No 3D)
Space Shuttle Space Shuttle
Section XIV - Appendixes
D-38 VT MAK
Spot Report Generator
2S19 Msta-S (No 3D), A-10 Thunderbolt, A-4 Skyhawk (No 3D), Aardvark JSFU (No 3D), AAVC7A1 Landing Vehicle, Ababil UAV (No 3D), Achzarit APC (No 3D), Actros AHSVS (No 3D), Admiral Grigorovich-class Frigate (No 3D), Afghan Police Officer, Afghan Soldier, African Insurgent, Agosta 90B-class Submarine (No 3D), AgustaWestland AW101 (No 3D), Agust- aWestland AW109 (No 3D), AH-1W SuperCobra, AH-64A Apache, AH-6 Little Bird (No 3D), Ahmad Yani-class Frigate, Aircraft Carrier, Akula-class Submarine (No 3D), Albatros-class Fast Attack (No 3D), AMX (No 3D), AMX-10RC (No 3D), AMX- 30D (No 3D), AMX-30 MBT, AMX-56 Leclerc MBT, Antonov-
class (No 3D), AN/BLQ-11 UUV (No 3D), Patriot Radar AN/MPQ- 65, Aquitaine-class Frigate (No 3D), Aravis MRAP (No 3D), Arjun MBT (No 3D), Arleigh Burke-class Destroyer, AS 332 Super Puma (No 3D), AS 532 Cougar (No 3D), AS 550 Fennec (No 3D), AS-365 Dauphin (No 3D), AS-565 Panther (No 3D), AS-90 Artillery, ASCOD Ulan AIFV (No 3D), ASTROS II MLRS
(No 3D), ATF Dingo (No 3D), AUF1 155mm Howitzer (No 3D), Auverland A4 AVL (No 3D), AV-8B Harrier II, B-2 Spirit, Badger AEV (No 3D), BAE CT-155 Hawk (No 3D), Bandvagn 206 (No
3D), Bay-class DLS (No 3D), Bay-class Patrol Boat (No 3D), Beaver AVLB (No 3D), Bell 412 (No 3D), Bell 206 JetRanger (No 3D), Bell 406 (No 3D), Bergepanzer 2 ARV (No 3D), Bison APC (No 3D), BMP-1 AFV, BMP-2 AFV, BN-2 Islander (No 3D),
Border Patrol Agent, Brandenburg-class Frigate (No 3D), Braun- schweig-class Corvette (No 3D), Brazilian Soldier, Bremen-class Frigate (No 3D), BTR-60 APC, BTR-80 APC, BTR-90, Buffalo
MRAP III, Buffel ARV (No 3D), Bushmaster PMV (No 3D), C-130 Hercules, C-17 Globemaster III (No 3D), C-5 Galaxy (No 3D), C1 Ariete MBT (No 3D), Cadillac Gage Commando V-150 (No 3D), CAESAR SP Howitzer, Canadair CT-114 (No 3D), Cape-class Patrol Boat (No 3D), Centauro B1 (No 3D), Cessna Citation (No 3D), CH-148 Cyclone (No 3D), CH-149 Cormorant, CH-46E Sea Knight, CH-47 Chinook (No 3D), CH-53E Super Stallion, Chal- lenger-class Submarine (No 3D), Charles De Gaulle R91 (No 3D), Chengdu J-7 (No 3D), Chilean AT4, Chilean IMI Galil, Chilean M16-M203, Chilean M16, Chilean M240, Chilean M249, Chilean M4, Chilean M60, Colombian Police Officer, Colombian Soldier, Cougar FSV, Coyote APC (No 3D), CUCV II (No 3D), CV9035 AFV, Cypher VTUAV, Dabur-class Patrol Boat (No 3D), Dardo IFV (No 3D), Dassault Atlantic (No 3D), Dassault Mystere- Falcon 20 (No 3D), Dassault Mystere-Falcon 900 (No 3D), De Zeven Provincien Class Frigate (No 3D), Defense Satellite, Delta III-class Submarine (No 3D), Delta IV-class Submarine (No 3D), DI AK-47, DI Lasing (CIS), DI Lasing (US), DI RPG, DI SMAW
And Rifle, DNG/DCL (No 3D), Dolphin-class Submarine (No 3D)
Spot Report Generator
Dragon Warrior VTUAV, E-2 Hawkeye, E-3 Sentry, EA-6B Prowler, EC 135 (No 3D), EC 635 (No 3D), EC145 (No 3D),
EC665 Eurocopter Tiger (No 3D), EC725 Caracal (No 3D), Echo- class Survey Ship (No 3D), EE-9 Cascavel (No 3D), EH101 Merlin (No 3D), Emergency Medical Technician, EMT Aladin (No 3D), EMT Luna (No 3D), ERC 90 Sagaie (No 3D), Eridan-class Minehunter (No 3D), ESK Mungo (No 3D), Eurofighter Typhoon, European Soldier, F-117A Nighthawk, F-15 Eagle, F-16A Fighting Falcon, F-22P Zulfiquar-class Frigate (No 3D), F-22 Raptor (No 3D), F-35 Lightning II, Fatahillah-class Frigate (No 3D), Fenneck, Floreal-class Frigate (No 3D), Flyvefisken-class Patrol Boat (No 3D), Ford Ambulance (Boston), Ford Ambulance, Ford Pickup Truck (White), Ford Pickup Truck (Red), Franken- thal-class Minehunter (No 3D), Freccia IFV (No 3D), LCS Freedom Class (No 3D), Fridtjof Nansen-class (No 3D), Fuchs APC (No 3D), FV 510 Warrior (No 3D), FV101 Scorpion CVR, FV107 Scimitar, FV4030/4 Challenger MBT, FV4034 Challenger 2 MBT (No 3D), FV432 APC (No 3D), F/A-18 Hornet, GAZ-69
Utility Vehicle, Gepard-class Frigate (No 3D), Ghillie Suit Soldier, GMC Yukon, Gotland-class Submarine (No 3D), Grisha-class Corvette (No 3D), Grizzly APC (No 3D), GTK Boxer APC (No 3D), Guided Missile Destroyer, Krivak-class Guided Missile Frigate, Halifax-class Frigate (No 3D), Hamina-class Fast Attack (No 3D), Harbin SH-5 ASW (No 3D), Hauk-class Fast Attack (No 3D), Hermes 450 (No 3D), HH-65 Dolphin (No 3D), HMMWV
Utility Vehicle, HMMWV with Avenger, HMMWV with M2, HMMWV with Shelter, HMMWV with TOW launcher, Holland Class OPV (No 3D), Husky ARV (No 3D), Il-76 Candid (No 3D), LCS Independence Class (No 3D), Insurgent, Invincible-class Carrier (No 3D), Iranian Soldier, Iraqi Police Officer, Iraqi Soldier, Iroquois-class Destroyer (No 3D), ISIS Fighter, Island-class Patrol Vessel (No 3D), Iveco LMV (No 3D), Jacinto-class Corvette (No 3D), Jackal MWMIK (No 3D), L-class Frigate (No 3D), K1A1 MBT (No 3D), KA-50 Hokum, Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), KCR-40 Clurit-class Fast Attack (No 3D), KD-III-class Destroyer (No 3D), Keeper-class (WLM) (No 3D), Khareff-class Corvette (No 3D), Kilo-class Submarine (No 3D), Kingston-class Patrol vessel, Kirov-class Guided Missile Cruiser (No 3D), Kurdish Fighter, Kuznetsov-class (No 3D), L 14 Albion (No 3D), L-118 Howitzer (No 3D), La Fayette-class Frigate (No 3D), Land Rover Wolf (No 3D), Land Rover, LAPV Enok (No 3D), LAV III APC, LCAC, Legend Class (WMSL),
Leopard 2 Tank, LG1 Howitzer (No 3D), Libyan Police Officer, Libyan Soldier, LIV (SO) Serval (No 3D), Lockheed L-1011 (No 3D), Los Angeles-Class Submarine, LPH01 Ocean (No 3D), Harpers Ferry-class LSD, Lupo-class Frigate (No 3D)
Section XIV - Appendixes
D-40 VT MAK
Spot Report Generator
M-71 Howitzer (No 3D), M109 Howitzer, M1126 Stryker ICV, M113 APC, M1A2 Abrams MBT, M270 MLRS, M2A2 Bradley
IFV, M35 Truck, M3A2 Bradley CFV, M577A2 Command Post, M58 MICLIC, M777 Howitzer (No 3D), M88 Medium Recovery Vehicle, M939A2 5-Ton Truck, M977 HEMTT Cargo Truck, M978 HEMTT Fuel Truck, M993 MLRS, M9 ACE, Maestrale- class Frigate (No 3D), Mamba APC (No 3D), Maveric UAS (No 3D), MBT 2000 (No 3D), MD 500 (No 3D), Merkava III MBT (No
3D), Merkava IV MBT (No 3D), MH-47 Chinook (No 3D), MH- 60L Black Hawk DAP (No 3D), MH-60 Black Hawk, MH-6 Little Bird (No 3D), Mi-17 Hip (No 3D), Mi-24 Hind, Mi-28 Havoc, Mi- 2 Hoplite, Mideast Combatant, Mideast Combatant with RPG, MiG-27 Flogger, MiG-29 Fulcrum, Milgem Class Corvette, M901 Patriot Launcher, Patriot Air Defense System (PAC-3), Mirage 2000, Mirage F1, Mistral Class AAS (No 3D), MO-120RT-61 Mortar, Mohajer UAV (No 3D), Moudge-class Frigate (No 3D), MOWAG Duro (No 3D), MOWAG Eagle (No 3D), MQ-4C Triton, MQ-8B Fire Scout, MQ-9 Reaper UAV, MRAP-ATV, MRAP-CAT
II Cougar, MRAP-CAT I MaxxPro, MT-LB APC, Namer APC (No 3D), Nanchang Q-5 (No 3D), Nanuchka III-class (No 3D), Navistar 7000 (No 3D), Neustrashimyy-class Frigate (No 3D), NH90-N1 (No 3D), Nimitz-class Carrier, Niteroi-class Frigate (No 3D), OH-58 Kiowa, Ohio-class Submarine, Oksoy-class Minehu- nter (No 3D), Oscar-class Submarine (No 3D), P-3 Orion, Paki- stani Police Officer, Pakistani Soldier, Panhard AML-245 (No 3D), Panhard M3 APC (No 3D), Panther CLV (No 3D), Panzer- haubitze 2000 Howitzer, Patria AMV (No 3D), EPP-III Patriot Power Generator, Patriot Engagement Control Sys, Pauk-class Corvette (No 3D), Pegaso 3046 APC (No 3D), PLZ-45 Howitzer (No 3D), Police Officer, Pomornik (Zubr)-class LCAC (No 3D), MQ-1 Predator, PT-91 Twardy MBT (No 3D), Puma AFV (No 3D), Puma CEV (No 3D), Queen Elizabeth-class Carrier (No 3D), RAH-66 Comanche, Rapier SAM (No 3D), RDE KZO (No 3D), REMUS UUV, Renault GBC 180 Truck (No 3D), RG-31 Nyala (No 3D), Rigid-Hulled Inflatable Boat, River-class Patrol Vessel (No 3D), Romeo-class Submarine, RQ-11 Raven UAV, RQ-4 Global Hawk UAV, RQ-7 Shadow UAV (No 3D), Rubis-Class Subma- rine, Russian Rebels, SA 330 Puma (No 3D), SA 342 Gazelle (No 3D), SA-15 Gauntlet SAM, SA-19 Grison, SA-6 Gainful SAM, SA-9 Gaskin SAM System, Saar 4-class Missile Boat (No 3D), Saar 4.5-class Missile Boat (No 3D), Saar 5-class Corvette (No 3D), Sachsen-class Frigate (No 3D), SAGEM Sperwer (No 3D), ScanEagle UAV (No 3D), Scorpene-class Submarine (No 3D), Sentinel-class (WPC) (No 3D), Sergeant M16, SH-3 Sea King (No 3D), SH-60 Seahawk, Shenyang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), Siera II-class Submarine (No 3D), Sigma 9113-class Frigate, Skjold-class Patrol (No 3D), Slava-class Guided Missile Cruiser (No 3D), Sodermanland-class Submarine (No 3D), Somali Police Officer
Spot Report Generator (continued)
Somali Soldier, Song-class Submarine, Sonobuoy (Passive), Sovremennyy-class Destroyer, Space Shuttle, Steregushchiy- class Frigate (No 3D), SU-25 Frogfoot, SU-27 Flanker, Su-37 Flanker, Sudanese Police Officer, Sudanese Soldier, Super Dvora Mark II (No 3D), Suspect, Syrian Police Officer, Syrian Soldier, T-69 MBT, T-72 MBT, T-80 MBT, T-84 MBT (No 3D), T90A
MBT (No 3D), Taliban, Tarantul-class Corvette (No 3D), Taurus ARV (No 3D), Technical Truck, Tiger-class Fast Attack Craft (No 3D), Tornado ADV (No 3D), Trafalgar-class Submarine (No 3D), Triomphant-Class Submarine (No 3D), TRM 1000 Truck (No 3D), Tu-160 Blackjack (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 093 (Shang-class) Submarine (No 3D), Type 094 (Jin-class) Submarine (No 3D), Type 209 Submarine (No 3D), Type 212 Submarine (No 3D), Type 42 Destroyer (No 3D), Type 85 (YW 531H) APC (No 3D), Type 45 Destroyer, Type 10 MBT (No 3D), Type 22 Frigate (No 3D), Type 23 Frigate, Type 90 Kyu-maru MBT (No 3D), Type 99 MBT (No 3D), Udaloy-class Destroyer, Ugandan Police Officer, Ugandan Soldier, UH-1N Twin Huey (No 3D), UH-60 Blackhawk, UH-72 Lakota (No 3D), UK Soldier, Ula-class Submarine (No 3D), URO VAMTAC (No 3D), US Air Force, US Army Medic, US EOD, US Navy With Binoculars, US Navy, National Security Cutter, Hamilton Class Cutter WHEC, USMC M16-M203, USMC M16, USMC M240, USMC M249, USMC M4, US Army AT4, US Army Javelin, US Army M16-M203, US Army M16, US Army M240, US Army M249, US Army M4, US Army M60, US Army M9, V-22 Osprey (No 3D), VAB APC, Vanguard-class Submarine (No 3D), VBCI APC (No 3D), VBL ATV, Victor II-class Submarine (No 3D), Victoria-class (No 3D), Victory-class Corvette (No 3D), VLRA 4x4 Truck (No 3D), VLRA 6x6 Truck (No 3D), VM 90 LSVW (No
3D), Walrus-class submarine (No 3D), Westland Lynx (No 3D), Wiesel AWC (No 3D), Marine Protector Class Patrol Boat, WS- 61 Sea King (No 3D), WZ551 APC (No 3D), Xian H-6 Badger (No 3D), Xian JH-7 (No 3D), XM7 FIST-Bradley, Yuan-class Submarine (No 3D), ZIL-135 8x8 Truck, ZPU-4 AA Gun, ZSU- 23-4 Shilka
Section XIV - Appendixes
D-42 VT MAK
Spot Report Receiver
2S19 Msta-S (No 3D), A-10 Thunderbolt, A-4 Skyhawk (No 3D), Aardvark JSFU (No 3D), AAVC7A1 Landing Vehicle, Ababil UAV (No 3D), Achzarit APC (No 3D), Actros AHSVS (No 3D), Admiral Grigorovich-class Frigate (No 3D), Afghan Police Officer, Afghan Soldier, African Insurgent, Agosta 90B-class Submarine (No 3D), AgustaWestland AW101 (No 3D), Agust- aWestland AW109 (No 3D), AH-1W SuperCobra, AH-64A Apache, AH-6 Little Bird (No 3D), Ahmad Yani-class Frigate, Aircraft Carrier, Akula-class Submarine (No 3D), Albatros-class Fast Attack (No 3D), AMX (No 3D), AMX-10RC (No 3D), AMX- 30D (No 3D), AMX-30 MBT, AMX-56 Leclerc MBT, Antonov-
class (No 3D), AN/BLQ-11 UUV (No 3D), Patriot Radar AN/MPQ- 65, Aquitaine-class Frigate (No 3D), Aravis MRAP (No 3D), Arjun MBT (No 3D), Arleigh Burke-class Destroyer, AS 332 Super Puma (No 3D), AS 532 Cougar (No 3D), AS 550 Fennec (No 3D), AS-365 Dauphin (No 3D), AS-565 Panther (No 3D), AS-90 Artillery, ASCOD Ulan AIFV (No 3D), ASTROS II MLRS
(No 3D), ATF Dingo (No 3D), AUF1 155mm Howitzer (No 3D), Auverland A4 AVL (No 3D), AV-8B Harrier II, B-2 Spirit, Badger AEV (No 3D), BAE CT-155 Hawk (No 3D), Bandvagn 206 (No
3D), Bay-class DLS (No 3D), Bay-class Patrol Boat (No 3D), Beaver AVLB (No 3D), Bell 412 (No 3D), Bell 206 JetRanger (No 3D), Bell 406 (No 3D), Bergepanzer 2 ARV (No 3D), Bison APC (No 3D), BMP-1 AFV, BMP-2 AFV, BN-2 Islander (No 3D),
Border Patrol Agent, Brandenburg-class Frigate (No 3D), Braun- schweig-class Corvette (No 3D), Brazilian Soldier, Bremen-class Frigate (No 3D), BTR-60 APC, BTR-80 APC, BTR-90, Buffalo
MRAP III, Buffel ARV (No 3D), Bushmaster PMV (No 3D), C-130 Hercules, C-17 Globemaster III (No 3D), C-5 Galaxy (No 3D), C1 Ariete MBT (No 3D), Cadillac Gage Commando V-150 (No 3D), CAESAR SP Howitzer, Canadair CT-114 (No 3D), Cape-class Patrol Boat (No 3D), Centauro B1 (No 3D), Cessna Citation (No 3D), CH-148 Cyclone (No 3D), CH-149 Cormorant, CH-46E Sea Knight, CH-47 Chinook (No 3D), CH-53E Super Stallion, Chal- lenger-class Submarine (No 3D), Charles De Gaulle R91 (No 3D), Chengdu J-7 (No 3D), Chilean AT4, Chilean IMI Galil, Chilean M16-M203, Chilean M16, Chilean M240, Chilean M249, Chilean M4, Chilean M60, Colombian Police Officer, Colombian Soldier, Cougar FSV, Coyote APC (No 3D), CUCV II (No 3D), CV9035 AFV, Dabur-class Patrol Boat (No 3D), Dardo IFV (No 3D), Dassault Atlantic (No 3D), Dassault Mystere-Falcon 20 (No 3D), Dassault Mystere-Falcon 900 (No 3D), De Zeven Provincien Class Frigate (No 3D), Defense Satellite, Delta III-class Subma- rine (No 3D), Delta IV-class Submarine (No 3D), DI AK-47, DI Lasing (CIS), DI Lasing (US), DI RPG, DI SMAW And Rifle, DNG/DCL (No 3D), Dolphin-class Submarine (No 3D), E-2 Hawkeye
Spot Report Receiver
E-3 Sentry, EA-6B Prowler, EC 135 (No 3D), EC 635 (No 3D),
EC145 (No 3D), EC665 Eurocopter Tiger (No 3D), EC725 Caracal (No 3D), Echo-class Survey Ship (No 3D), EE-9 Cascavel (No 3D), EH101 Merlin (No 3D), Emergency Medical Technician, EMT Aladin (No 3D), EMT Luna (No 3D), ERC 90 Sagaie (No 3D), Eridan-class Minehunter (No 3D), ESK Mungo (No 3D), Eurofighter Typhoon, European Soldier, F-117A Nighthawk, F- 15 Eagle, F-16A Fighting Falcon, F-22P Zulfiquar-class Frigate (No 3D), F-22 Raptor (No 3D), F-35 Lightning II, Fatahillah-class Frigate (No 3D), Fenneck, Floreal-class Frigate (No 3D), Flyve- fisken-class Patrol Boat (No 3D), Ford Ambulance (Boston), Ford Ambulance, Ford Pickup Truck (White), Ford Pickup Truck (Red), Frankenthal-class Minehunter (No 3D), Freccia IFV (No 3D), LCS Freedom Class (No 3D), Fridtjof Nansen-class (No 3D), Fuchs APC (No 3D), FV 510 Warrior (No 3D), FV101 Scorpion CVR, FV107 Scimitar, FV4030/4 Challenger MBT, FV4034 Challenger 2 MBT (No 3D), FV432 APC (No 3D), F/A-18 Hornet, GAZ-69
Utility Vehicle, Gepard-class Frigate (No 3D), Ghillie Suit Soldier, GMC Yukon, Gotland-class Submarine (No 3D), Grisha-class Corvette (No 3D), Grizzly APC (No 3D), GTK Boxer APC (No 3D), Guided Missile Destroyer, Krivak-class Guided Missile Frigate, Halifax-class Frigate (No 3D), Hamina-class Fast Attack (No 3D), Harbin SH-5 ASW (No 3D), Hauk-class Fast Attack (No 3D), Hermes 450 (No 3D), HH-65 Dolphin (No 3D), HMMWV
Utility Vehicle, HMMWV with Avenger, HMMWV with M2, HMMWV with Shelter, HMMWV with TOW launcher, Holland Class OPV (No 3D), Husky ARV (No 3D), Il-76 Candid (No 3D), LCS Independence Class (No 3D), Insurgent, Invincible-class Carrier (No 3D), Iranian Soldier, Iraqi Police Officer, Iraqi Soldier, Iroquois-class Destroyer (No 3D), ISIS Fighter, Island-class Patrol Vessel (No 3D), Iveco LMV (No 3D), Jacinto-class Corvette (No 3D), Jackal MWMIK (No 3D), L-class Frigate (No 3D), K1A1 MBT (No 3D), KA-50 Hokum, Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), KCR-40 Clurit-class Fast Attack (No 3D), KD-III-class Destroyer (No 3D), Keeper-class (WLM) (No 3D), Khareff-class Corvette (No 3D), Kilo-class Submarine (No 3D), Kingston-class Patrol vessel, Kirov-class Guided Missile Cruiser (No 3D), Kurdish Fighter, Kuznetsov-class (No 3D), L 14 Albion (No 3D), L-118 Howitzer (No 3D), La Fayette-class Frigate (No 3D), Land Rover Wolf (No 3D), Land Rover, LAPV Enok (No 3D), LAV III APC, LCAC, Legend Class (WMSL),
Leopard 2 Tank, LG1 Howitzer (No 3D), Libyan Police Officer, Libyan Soldier, LIV (SO) Serval (No 3D), Lockheed L-1011 (No 3D), Los Angeles-Class Submarine, LPH01 Ocean (No 3D), Harpers Ferry-class LSD, Lupo-class Frigate (No 3D), M-71 Howitzer (No 3D), M109 Howitzer, M1126 Stryker ICV
Section XIV - Appendixes
D-44 VT MAK
Spot Report Receiver
M113 APC, M1A2 Abrams MBT, M270 MLRS, M2A2 Bradley
IFV, M35 Truck, M3A2 Bradley CFV, M577A2 Command Post, M58 MICLIC, M777 Howitzer (No 3D), M88 Medium Recovery Vehicle, M939A2 5-Ton Truck, M977 HEMTT Cargo Truck, M978 HEMTT Fuel Truck, M993 MLRS, M9 ACE, Maestrale- class Frigate (No 3D), Mamba APC (No 3D), Maveric UAS (No 3D), MBT 2000 (No 3D), MD 500 (No 3D), Merkava III MBT (No
3D), Merkava IV MBT (No 3D), MH-47 Chinook (No 3D), MH- 60L Black Hawk DAP (No 3D), MH-60 Black Hawk, MH-6 Little Bird (No 3D), Mi-17 Hip (No 3D), Mi-24 Hind, Mi-28 Havoc, Mi- 2 Hoplite, Mideast Combatant, Mideast Combatant with RPG, MiG-27 Flogger, MiG-29 Fulcrum, Milgem Class Corvette, M901 Patriot Launcher, Patriot Air Defense System (PAC-3), Mirage 2000, Mirage F1, Mistral Class AAS (No 3D), MO-120RT-61 Mortar, Mohajer UAV (No 3D), Moudge-class Frigate (No 3D), MOWAG Duro (No 3D), MOWAG Eagle (No 3D), MQ-4C Triton, MQ-8B Fire Scout, MQ-9 Reaper UAV, MRAP-ATV, MRAP-CAT
II Cougar, MRAP-CAT I MaxxPro, MT-LB APC, Namer APC (No 3D), Nanchang Q-5 (No 3D), Nanuchka III-class (No 3D), Navistar 7000 (No 3D), Neustrashimyy-class Frigate (No 3D), NH90-N1 (No 3D), Nimitz-class Carrier, Niteroi-class Frigate (No 3D), OH-58 Kiowa, Ohio-class Submarine, Oksoy-class Minehu- nter (No 3D), Oscar-class Submarine (No 3D), P-3 Orion, Paki- stani Police Officer, Pakistani Soldier, Panhard AML-245 (No 3D), Panhard M3 APC (No 3D), Panther CLV (No 3D), Panzer- haubitze 2000 Howitzer, Patria AMV (No 3D), EPP-III Patriot Power Generator, Patriot Engagement Control Sys, Pauk-class Corvette (No 3D), Pegaso 3046 APC (No 3D), PLZ-45 Howitzer (No 3D), Police Officer, Pomornik (Zubr)-class LCAC (No 3D), MQ-1 Predator, PT-91 Twardy MBT (No 3D), Puma AFV (No 3D), Puma CEV (No 3D), Queen Elizabeth-class Carrier (No 3D), RAH-66 Comanche, Rapier SAM (No 3D), RDE KZO (No 3D), REMUS UUV, Renault GBC 180 Truck (No 3D), RG-31 Nyala (No 3D), Rigid-Hulled Inflatable Boat, River-class Patrol Vessel (No 3D), Romeo-class Submarine, RQ-11 Raven UAV, RQ-4 Global Hawk UAV, RQ-7 Shadow UAV (No 3D), Rubis-Class Subma- rine, Russian Rebels, SA 330 Puma (No 3D), SA 342 Gazelle (No 3D), SA-15 Gauntlet SAM, SA-19 Grison, SA-6 Gainful SAM, SA-9 Gaskin SAM System, Sachsen-class Frigate (No 3D), SAGEM Sperwer (No 3D), ScanEagle UAV (No 3D), Scorpene- class Submarine (No 3D), Sentinel-class (WPC) (No 3D), Sergeant M16, SH-3 Sea King (No 3D), SH-60 Seahawk, Shen- yang J-11 Flanker (No 3D), Shenyang J-8 Finback (No 3D), Siera II-class Submarine (No 3D), Sigma 9113-class Frigate, Skjold- class Patrol (No 3D), Slava-class Guided Missile Cruiser (No 3D), Sodermanland-class Submarine (No 3D), Somali Police Officer, Somali Soldier, Song-class Submarine, Sovremennyy-class Destroyer, Space Shuttle, Steregushchiy-class Frigate (No 3D), SU-25 Frogfoot
Spot Report Receiver (continued)
Stinger Missile Launcher
SU-27 Flanker, Su-37 Flanker, Sudanese Police Officer, Suda- nese Soldier, Super Dvora Mark II (No 3D), Suspect, Syrian Police Officer, Syrian Soldier, T-69 MBT, T-72 MBT, T-80 MBT, T-84 MBT (No 3D), T90A MBT (No 3D), Taliban, Tarantul-class Corvette (No 3D), Taurus ARV (No 3D), Technical Truck, Tiger- class Fast Attack Craft (No 3D), Tornado ADV (No 3D), Trafalgar-class Submarine (No 3D), Triomphant-Class Submarine (No 3D), TRM 1000 Truck (No 3D), Tu-160 Blackjack (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 093 (Shang-class) Submarine (No 3D), Type 094 (Jin-class) Submarine (No 3D), Type 209 Submarine (No 3D), Type 212 Submarine (No 3D), Type 42 Destroyer (No 3D), Type 85 (YW 531H) APC (No 3D), Type 45 Destroyer, Type 10 MBT (No 3D), Type 22 Frigate (No 3D), Type 23 Frigate, Type 90 Kyu-maru MBT (No 3D), Type 99 MBT (No 3D), Udaloy-class Destroyer, Ugandan Police Officer, Ugandan Soldier, UH-1N Twin Huey (No 3D), UH-60 Blackhawk, UH-72 Lakota (No 3D), UK Soldier, Ula-class Submarine (No 3D), URO VAMTAC (No 3D), US Air Force, US Army Medic, US EOD, US Navy With Binoculars, US Navy, National Security Cutter, Hamilton Class Cutter WHEC, USMC M16-M203, USMC M16, USMC M240, USMC M249, USMC M4, US Army AT4,
US Army Javelin, US Army M16-M203, US Army M16, US Army M240, US Army M249, US Army M4, US Army M60, US
Army M9, V-22 Osprey (No 3D), VAB APC, Vanguard-class Submarine (No 3D), VBCI APC (No 3D), VBL ATV, Victor II-class Submarine (No 3D), Victoria-class (No 3D), Victory-class Corvette (No 3D), VLRA 4x4 Truck (No 3D), VLRA 6x6 Truck (No 3D), VM 90 LSVW (No 3D), Walrus-class submarine (No 3D), Westland Lynx (No 3D), Wiesel AWC (No 3D), Marine Protector Class Patrol Boat, WS-61 Sea King (No 3D), WZ551 APC (No 3D), Xian H-6 Badger (No 3D), Xian JH-7 (No 3D), XM7 FIST-Bradley, Yuan-class Submarine (No 3D), ZIL-135 8x8 Truck, ZPU-4 AA Gun, ZSU-23-4 Shilka
HMMWV with Avenger
Section XIV - Appendixes
D-46 VT MAK
Subsurface Entity Default
Agosta 90B-class Submarine (No 3D), Akula-class Submarine (No 3D), AN/BLQ-11 UUV (No 3D), Astute-class Submarine (No 3D), Challenger-class Submarine (No 3D), Delta III-class Subma- rine (No 3D), Delta IV-class Submarine (No 3D), Dolphin-class Submarine (No 3D), Gotland-class Submarine (No 3D), Kilo-class Submarine (No 3D), Los Angeles-Class Submarine, Mk-46 MOD 5 Torpedo, Mk-48 ADCAP Torpedo, Ohio-class Submarine, Oscar-class Submarine (No 3D), REMUS UUV, Romeo-class Submarine, Rubis-Class Submarine, Scorpene-class Submarine (No 3D), Siera II-class Submarine (No 3D), Sodermanland-class Submarine (No 3D), Song-class Submarine, Trafalgar-class Submarine (No 3D), Triomphant-Class Submarine (No 3D), Type 093 (Shang-class) Submarine (No 3D), Type 094 (Jin-class) Submarine (No 3D), Type 209 Submarine (No 3D), Type 212 Submarine (No 3D), Ula-class Submarine (No 3D), Vanguard- class Submarine (No 3D), Victor II-class Submarine (No 3D), Victoria-class (No 3D), Walrus-class submarine (No 3D), Yuan- class Submarine (No 3D)
Subsurface Agosta 90B-class Submarine (No 3D), Akula-class Submarine (No 3D), AN/BLQ-11 UUV (No 3D), Astute-class Submarine (No 3D), Challenger-class Submarine (No 3D), Delta III-class Subma- rine (No 3D), Delta IV-class Submarine (No 3D), Dolphin-class Submarine (No 3D), Gotland-class Submarine (No 3D), Kilo-class Submarine (No 3D), Los Angeles-Class Submarine, Mk-46 MOD 5 Torpedo, Mk-48 ADCAP Torpedo, Ohio-class Submarine, Oscar-class Submarine (No 3D), REMUS UUV, Romeo-class Submarine, Rubis-Class Submarine, Scorpene-class Submarine (No 3D), Siera II-class Submarine (No 3D), Sodermanland-class Submarine (No 3D), Song-class Submarine, Trafalgar-class Submarine (No 3D), Triomphant-Class Submarine (No 3D), Type 093 (Shang-class) Submarine (No 3D), Type 094 (Jin-class) Submarine (No 3D), Type 209 Submarine (No 3D), Type 212 Submarine (No 3D), Ula-class Submarine (No 3D), Vanguard- class Submarine (No 3D), Victor II-class Submarine (No 3D), Victoria-class (No 3D), Walrus-class submarine (No 3D), Yuan- class Submarine (No 3D)
Surface Entity Default
D-48
Agosta 90B-class Submarine (No 3D), Ahmad Yani-class Frigate, Aircraft Carrier, Akula-class Submarine (No 3D), Albatros-class Fast Attack (No 3D), Alta-class Minehunter (No 3D), AN/BLQ-11 UUV (No 3D), Aquitaine-class Frigate (No 3D), Arleigh Burke- class Destroyer, Asagiri-class Destroyer (No 3D), Astute-class Submarine (No 3D), Auto Ferry, Bay-class DLS (No 3D), Bay- class Patrol Boat (No 3D), Brandenburg-class Frigate (No 3D), Braunschweig-class Corvette (No 3D), Bremen-class Frigate (No 3D), Cape-class Patrol Boat (No 3D), Challenger-class Submarine (No 3D), Charles De Gaulle R91 (No 3D), Container Ship, Container Ship Loaded, Cruise Ship, Dabur-class Patrol Boat (No 3D), De Zeven Provincien Class Frigate (No 3D), Delhi-class Destroyer (No 3D), Delta III-class Submarine (No 3D), Delta IV- class Submarine (No 3D), Dolphin-class Submarine (No 3D), Durand de la Penne-class Destroyer (No 3D), Echo-class Survey Ship (No 3D), Eridan-class Minehunter (No 3D), F-22P Zulfiquar- class Frigate (No 3D), Fatahillah-class Frigate (No 3D), Fishing Boat, Floreal-class Frigate (No 3D), Flyvefisken-class Patrol Boat (No 3D), Frankenthal-class Minehunter (No 3D), LCS Freedom Class (No 3D), Gaeta-class Minehunter, Gotland-class Subma- rine (No 3D), Guided Missile Destroyer, Halifax-class Frigate (No 3D), Hamina-class Fast Attack (No 3D), Hauk-class Fast Attack (No 3D), Henry J Kaiser-class Oiler (No 3D), Holland Class OPV (No 3D), Horizon-class Destroyer (No 3D), Hunt-class Minehu- nter (No 3D), LCS Independence Class (No 3D), Iroquois-class Destroyer (No 3D), Island-class Patrol Vessel (No 3D), L-class Frigate (No 3D), Jet Ski, KAAN 19 Class Fast Patrol Craft, Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), KCR- 40 Clurit-class Fast Attack (No 3D), KD-III-class Destroyer (No 3D), Keeper-class (WLM) (No 3D), Khareff-class Corvette (No 3D), Kilo-class Submarine (No 3D), Kingston-class Patrol vessel, Kirov-class Guided Missile Cruiser (No 3D), Kolkata-class Destroyer (No 3D), Kuznetsov-class (No 3D), L 14 Albion (No 3D), La Fayette-class Frigate (No 3D), Legend Class (WMSL), Los Angeles-Class Submarine, LPH01 Ocean (No 3D), Harpers Ferry-class LSD, Lupo-class Frigate (No 3D), Maestrale-class Frigate (No 3D), Milgem Class Corvette, Osprey-class Mine CMS (No 3D), Mistral Class AAS (No 3D), Mk-46 MOD 5 Torpedo, Mk-48 ADCAP Torpedo, Moudge-class Frigate (No 3D), Murasame-class Destroyer (No 3D), Nimitz-class Carrier, Niteroi- class Frigate (No 3D), Ohio-class Submarine, Oksoy-class Mine- hunter (No 3D), Oscar-class Submarine (No 3D), Passenger Ferry, Queen Elizabeth-class Carrier (No 3D), REMUS UUV, Rigid-Hulled Inflatable Boat, Rigid-Hulled Inflatable Boat - Civilian, River-class Patrol Vessel (No 3D), Romeo-class Subma- rine, Rubis-Class Submarine, Runnymede-class Landing Craft Utility 2000 (No 3D), Saar 4-class Missile Boat (No 3D), Saar 4.5-class Missile Boat (No 3D), Saar 5-class Corvette (No 3D), Sachsen-class Frigate (No 3D), Sailboat, Sandown-class Minehu- nter (No 3D), Scorpene-class Submarine (No 3D), Sentinel-class (WPC) (No 3D), Siera II-class Submarine (No 3D), Sigma 9113- class Frigate, Skjold-class Patrol (No 3D), Slava-class Guided
Missile Cruiser (No 3D), Sodermanland-class Submarine (No 3D), SongS-celcatsiosnSuXbIVm-arAinpep,eSnodvixreems ennyy-class Destroyer, Super
Dvora Mark II (No 3D), Super Tanker, Trafalgar-class Submarine (No 3D), Triomphant-Class Submarine (No 3D), Tugboat, TVyTpMe AK 056 Jiangdao Corvette (No 3D), Type 093 (Shang-class)
Submarine (No 3D), Type 094 (Jin-class) Submarine (No 3D), Type 209 Submarine (No 3D), Type 212 Submarine (No 3D), Type 42 Destroyer (No 3D), Type-80 Class Large Patrol Boat,
Surface Entity Default (continued)
Surface Disaggre- gated Movement
Type 22 Frigate (No 3D), Type 23 Frigate, Udaloy-class Destroyer, Ula-class Submarine (No 3D), National Security Cutter, Hamilton Class Cutter WHEC, Vanguard-class Submarine (No 3D), Victor II-class Submarine (No 3D), Victoria-class (No 3D), Victory-class Corvette (No 3D), Walrus-class submarine (No 3D), Marine Protector Class Patrol Boat, Yuan-class Subma- rine (No 3D)
Large Ship Admiral Grigorovich-class Frigate (No 3D), Ahmad Yani-class Frigate, Aircraft Carrier, Alta-class Minehunter (No 3D), Aquit- aine-class Frigate (No 3D), Arleigh Burke-class Destroyer, Asagiri-class Destroyer (No 3D), Auto Ferry, Bay-class DLS (No 3D), Brandenburg-class Frigate (No 3D), Braunschweig-class Corvette (No 3D), Bremen-class Frigate (No 3D), Charles De Gaulle R91 (No 3D), Container Ship, Container Ship Loaded, Cruise Ship, De Zeven Provincien Class Frigate (No 3D), Delhi- class Destroyer (No 3D), Durand de la Penne-class Destroyer (No 3D), Eridan-class Minehunter (No 3D), F-22P Zulfiquar-class Frigate (No 3D), Fatahillah-class Frigate (No 3D), Fishing Boat, Floreal-class Frigate (No 3D), Flyvefisken-class Patrol Boat (No 3D), Frankenthal-class Minehunter (No 3D), LCS Freedom Class (No 3D), Fridtjof Nansen-class (No 3D), Gaeta-class Minehunter, Gepard-class Frigate (No 3D), Guided Missile Destroyer, Krivak- class Guided Missile Frigate, Halifax-class Frigate (No 3D), Henry J Kaiser-class Oiler (No 3D), Horizon-class Destroyer (No 3D), Hunt-class Minehunter (No 3D), LCS Independence Class (No 3D), Invincible-class Carrier (No 3D), Iroquois-class Destroyer (No 3D), L-class Frigate (No 3D), Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), KD-III-class Destroyer (No 3D), Keeper-class (WLM) (No 3D), Khareff-class Corvette (No 3D), Kingston-class Patrol vessel, Kirov-class Guided Missile Cruiser (No 3D), Kolkata-class Destroyer (No 3D), Kuznetsov- class (No 3D), L 14 Albion (No 3D), La Fayette-class Frigate (No 3D), Legend Class (WMSL), LPH01 Ocean (No 3D), Harpers Ferry-class LSD, Lupo-class Frigate (No 3D), Maestrale-class Frigate (No 3D), Milgem Class Corvette, Osprey-class Mine CMS (No 3D), Mistral Class AAS (No 3D), Moudge-class Frigate (No 3D), Murasame-class Destroyer (No 3D), Neustrashimyy-class Frigate (No 3D), Nimitz-class Carrier, Niteroi-class Frigate (No 3D), Oksoy-class Minehunter (No 3D), Passenger Ferry, Queen Elizabeth-class Carrier (No 3D), Runnymede-class Landing Craft Utility 2000 (No 3D), Sachsen-class Frigate (No 3D), Sandown- class Minehunter (No 3D), Sentinel-class (WPC) (No 3D), Sigma 9113-class Frigate, Slava-class Guided Missile Cruiser (No 3D), Sovremennyy-class Destroyer, Super Tanker, Tugboat, Type 056 Jiangdao Corvette (No 3D), Type 42 Destroyer (No 3D), Type-80 Class Large Patrol Boat, Type 45 Destroyer, Type 22 Frigate (No 3D), Type 23 Frigate, Udaloy-class Destroyer, National Security Cutter, Hamilton Class Cutter WHEC, Victory- class Corvette (No 3D), Marine Protector Class Patrol Boat
Surface Multiple Hit Damage
Admiral Grigorovich-class Frigate (No 3D), Gepard-class Frigate (No 3D), Grisha-class Corvette (No 3D), Krivak-class Guided Missile Frigate, Jacinto-class Corvette (No 3D), Nanuchka III- class (No 3D), Neustrashimyy-class Frigate (No 3D), Pauk-class Corvette (No 3D), Steregushchiy-class Frigate (No 3D), Tarantul- class Corvette (No 3D)
Section XIV - Appendixes
D-50 VT MAK
Small Surface Ships
Tactical Radar Jammer
Tanker Refueling Boom
Fleet-class USV (No 3D), Skiff (Green), Skiff, Speedboat, Tiara 3900 Yacht
E-2 Hawkeye, EA-6B Prowler KC-135 Stratotanker
Torpedo Warhead Mk-46 MOD 5 Torpedo, Mk-48 ADCAP Torpedo
TOW Missile Launcher
US Fighter Bomber Bomb Bay
US Heavy Bomber Bomb Bay
Vertical SAM Missile Launcher
HMMWV with TOW launcher, VM 90 LSVW (No 3D)
A-10 Thunderbolt, A-4 Skyhawk (No 3D), AMX (No 3D), AV-8B Harrier II, Eurofighter Typhoon, F-117A Nighthawk, F-15 Eagle, F-16A Fighting Falcon, F-22 Raptor (No 3D), F-35 Lightning II, F/A-18 Hornet, Mirage 2000, Mirage F1, Tornado ADV (No 3D), Xian JH-7 (No 3D)
B-2 Spirit, Harbin SH-5 ASW (No 3D), Il-76 Candid (No 3D), P-3 Orion, Xian H-6 Badger (No 3D)
Ahmad Yani-class Frigate, Alta-class Minehunter (No 3D), Aquit- aine-class Frigate (No 3D), Arleigh Burke-class Destroyer, Asagiri-class Destroyer (No 3D), Brandenburg-class Frigate (No 3D), Braunschweig-class Corvette (No 3D), Bremen-class Frigate (No 3D), Charles De Gaulle R91 (No 3D), De Zeven Provincien Class Frigate (No 3D), Delhi-class Destroyer (No 3D), Durand de la Penne-class Destroyer (No 3D), F-22P Zulfiquar-class Frigate (No 3D), Fatahillah-class Frigate (No 3D), Floreal-class Frigate (No 3D), Flyvefisken-class Patrol Boat (No 3D), Frankenthal- class Minehunter (No 3D), LCS Freedom Class (No 3D), Gepard- class Frigate (No 3D), Grisha-class Corvette (No 3D), Guided Missile Destroyer, Krivak-class Guided Missile Frigate, Halifax- class Frigate (No 3D), Hauk-class Fast Attack (No 3D), Horizon- class Destroyer (No 3D), Iroquois-class Destroyer (No 3D), L- class Frigate (No 3D), Karel Doorman Class Frigate (No 3D), KD- III-class Destroyer (No 3D), Khareff-class Corvette (No 3D), Kirov-class Guided Missile Cruiser (No 3D), Kolkata-class Destroyer (No 3D), Kuznetsov-class (No 3D), La Fayette-class Frigate (No 3D), Milgem Class Corvette, Moudge-class Frigate (No 3D), Murasame-class Destroyer (No 3D), Nanuchka III-class (No 3D), Neustrashimyy-class Frigate (No 3D), Niteroi-class Frigate (No 3D), Oksoy-class Minehunter (No 3D), Pauk-class Corvette (No 3D), Saar 4-class Missile Boat (No 3D), Saar 4.5- class Missile Boat (No 3D), Saar 5-class Corvette (No 3D), Sachsen-class Frigate (No 3D), Sigma 9113-class Frigate, Skjold-class Patrol (No 3D), Slava-class Guided Missile Cruiser (No 3D), Sovremennyy-class Destroyer, Tiger-class Fast Attack Craft (No 3D), Type 056 Jiangdao Corvette (No 3D), Type 42 Destroyer (No 3D), Type 45 Destroyer, Type 22 Frigate (No 3D), Type 23 Frigate, Udaloy-class Destroyer, Victory-class Corvette (No 3D)
Visual Sensor 2S19 Msta-S (No 3D), Aardvark JSFU (No 3D), AAVC7A1 Landing Vehicle, Ababil UAV (No 3D), Achzarit APC (No 3D), Actros AHSVS (No 3D), Afghan Police Officer, Afghan Soldier, African Insurgent, Ahmad Yani-class Frigate, AMX-10RC (No 3D), AMX-30D (No 3D), AMX-30 MBT, AMX-56 Leclerc MBT,
Aquitaine-class Frigate (No 3D), Aravis MRAP (No 3D), Arjun MBT (No 3D), AS-90 Artillery, Asagiri-class Destroyer (No 3D), ASCOD Ulan AIFV (No 3D), ASTROS II MLRS (No 3D), ATF
Dingo (No 3D), AUF1 155mm Howitzer (No 3D), Auto Ferry, Auverland A4 AVL (No 3D), Badger AEV (No 3D), Bandvagn 206 (No 3D), Beaver AVLB (No 3D), Bergepanzer 2 ARV (No 3D), Bison APC (No 3D), BMP-1 AFV, BMP-2 AFV, Border Patrol Agent, Brandenburg-class Frigate (No 3D), Braunschweig-class Corvette (No 3D), Brazilian Soldier, Bremen-class Frigate (No 3D), BTR-60 APC, BTR-80 APC, BTR-90, Buffalo MRAP III,
Buffel ARV (No 3D), Bushmaster PMV (No 3D), C1 Ariete MBT (No 3D), Cadillac Gage Commando V-150 (No 3D), CAESAR SP Howitzer, Car Bomb, Centauro B1 (No 3D), CH-46E Sea Knight, Chilean AT4, Chilean IMI Galil, Chilean M16-M203, Chilean M16, Chilean M240, Chilean M249, Chilean M4, Chilean M60, Colombian Police Officer, Colombian Soldier, Container Ship, Container Ship Loaded, Cougar FSV, Coyote APC (No 3D), Cruise Ship, CUCV II (No 3D), CV9035 AFV, Dardo IFV (No 3D),
De Zeven Provincien Class Frigate (No 3D), Delhi-class Destroyer (No 3D), DI AK-47, DI Lasing (CIS), DI Lasing (US), DI RPG, DI SMAW And Rifle, DNG/DCL (No 3D), Durand de la Penne-class Destroyer (No 3D), EE-9 Cascavel (No 3D), Emer- gency Medical Technician, EMT Aladin (No 3D), EMT Luna (No 3D), ERC 90 Sagaie (No 3D), Eridan-class Minehunter (No 3D), ESK Mungo (No 3D), European Soldier, F-22P Zulfiquar-class Frigate (No 3D), Fenneck, Fishing Boat, Fleet-class USV (No 3D), Floreal-class Frigate (No 3D), Flyvefisken-class Patrol Boat (No 3D), Ford Ambulance (Boston), Ford Ambulance, Ford Pickup Truck (White), Ford Pickup Truck (Red), Frankenthal- class Minehunter (No 3D), Freccia IFV (No 3D), LCS Freedom Class (No 3D), Fuchs APC (No 3D), FV 510 Warrior (No 3D), FV101 Scorpion CVR, FV107 Scimitar, FV4030/4 Challenger MBT, FV4034 Challenger 2 MBT (No 3D), FV432 APC (No 3D),
GAZ-69 Utility Vehicle, Ghillie Suit Soldier, GMC Yukon, Grizzly APC (No 3D), GTK Boxer APC (No 3D), HMMWV Utility Vehicle, HMMWV with M2, HMMWV with Shelter, HMMWV with TOW launcher, Husky ARV (No 3D), LCS Independence Class (No 3D), Insurgent, Invincible-class Carrier (No 3D), Iranian Soldier, Iraqi Police Officer, Iraqi Soldier, ISIS Fighter, Iveco LMV (No 3D)
Section XIV - Appendixes
D-52 VT MAK
Visual Sensor Jackal MWMIK (No 3D), L-class Frigate (No 3D), Jet Ski, K1A1 MBT (No 3D), KAAN 19 Class Fast Patrol Craft, Karel Doorman Class Frigate (No 3D), M-class Frigate (No 3D), Khareff-class Corvette (No 3D), Kolkata-class Destroyer (No 3D), Kurdish Fighter, L-118 Howitzer (No 3D), La Fayette-class Frigate (No 3D), Land Rover Wolf (No 3D), Land Rover, LAPV Enok (No 3D), LAV III APC, LCAC, Legend Class (WMSL), Leopard 2 Tank, Libyan Police Officer, Libyan Soldier, LIV (SO) Serval (No 3D), Lupo-class Frigate (No 3D), M109 Howitzer, M1126 Stryker ICV, M113 APC, M1A2 Abrams MBT, M2A2 Bradley IFV, M35 Truck, M3A2 Bradley CFV, M577A2 Command Post, M58 MICLIC, M88 Medium Recovery Vehicle, M939A2 5-Ton Truck, M977 HEMTT Cargo Truck, M978 HEMTT Fuel Truck, M993 MLRS, M9 ACE, Maestrale-class Frigate (No 3D), Mamba APC (No 3D), Maveric UAS (No 3D), MBT 2000 (No 3D),
Merkava III MBT (No 3D), Merkava IV MBT (No 3D), Mideast Combatant, Mideast Combatant with RPG, MO-120RT-61 Mortar, Mohajer UAV (No 3D), Moudge-class Frigate (No 3D), MOWAG Duro (No 3D), MOWAG Eagle (No 3D), MQ-8B Fire
Scout, MQ-9 Reaper UAV, MRAP-ATV, MRAP-CAT II Cougar, MRAP-CAT I MaxxPro, MT-LB APC, Murasame-class Destroyer (No 3D), Namer APC (No 3D), Navistar 7000 (No 3D), Niteroi- class Frigate (No 3D), Pakistani Police Officer, Pakistani Soldier, Panhard AML-245 (No 3D), Panhard M3 APC (No 3D), Panther CLV (No 3D), Panzerhaubitze 2000 Howitzer, Passenger Ferry, Patria AMV (No 3D), EPP-III Patriot Power Generator, Pegaso 3046 APC (No 3D), PLZ-45 Howitzer (No 3D), Police Officer, Pomornik (Zubr)-class LCAC (No 3D), MQ-1 Predator, PT-91 Twardy MBT (No 3D), Puma AFV (No 3D), Puma CEV (No 3D), RDE KZO (No 3D), Renault GBC 180 Truck (No 3D), RG-31
Nyala (No 3D), Rigid-Hulled Inflatable Boat, Rigid-Hulled Inflat- able Boat - Civilian, Roadside IED, RQ-11 Raven UAV, RQ-7 Shadow UAV (No 3D), Runnymede-class Landing Craft Utility 2000 (No 3D), Russian Rebels, Sachsen-class Frigate (No 3D), SAGEM Sperwer (No 3D), Sailboat, ScanEagle UAV (No 3D), Sergeant M16, Sigma 9113-class Frigate, Skiff (Green), Skiff, Somali Police Officer, Somali Soldier, Speedboat, Sudanese Police Officer, Sudanese Soldier, Suicide Bomber, Super Dvora Mark II (No 3D), Super Tanker, Suspect, Syrian Police Officer, Syrian Soldier, T-69 MBT, T-72 MBT, T-80 MBT, T-84 MBT (No
3D), T90A MBT (No 3D), Taliban, Taurus ARV (No 3D), Tech- nical Truck, Tiara 3900 Yacht, TRM 1000 Truck (No 3D), Tugboat, Type 85 (YW 531H) APC (No 3D), Type-80 Class Large Patrol Boat, Type 10 MBT (No 3D), Type 90 Kyu-maru MBT (No 3D), Type 99 MBT (No 3D)
Visual Sensor (continued)
Ugandan Police Officer, Ugandan Soldier, UK Soldier, URO VAMTAC (No 3D), US Air Force, US Army Medic, US EOD, US Navy With Binoculars, US Navy, National Security Cutter, Hamilton Class Cutter WHEC, USMC M16-M203, USMC M16, USMC M240, USMC M249, USMC M4, US Army AT4, US
Army Javelin, US Army M16-M203, US Army M16, US Army M240, US Army M249, US Army M4, US Army M60, US Army M9, VAB APC, VBCI APC (No 3D), VBL ATV, VLRA 4x4 Truck (No 3D), VLRA 6x6 Truck (No 3D), VM 90 LSVW (No 3D), Wiesel AWC (No 3D), WZ551 APC (No 3D), XM7 FIST-Bradley, ZIL-135 8x8 Truck, ZPU-4 AA Gun, ZSU-23-4 Shilka
Table D-3: Systems and Configured Scripted Tasks, EntityLevel.sms
System Scripted Tasks
System Scripted Tasks
120mm Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc 125mm Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc 14.5mm Quad Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc 25mm Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc 30mm Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc Cargo Door Open_Cargo_Door, Close_Cargo_Door
Sliding Door Open_Sliding_Door, Close_Sliding_Door
Anti-Submarine Missile (Vertically Launched)
DDG Embedded Support Craft (LAMPS/RHIB)
Launch_ASW_Missile Embedded_Sector_SAR
Fast Roping Deploy_Ropes, FastRopeInsertion
Fighter Jet Fixed_Wing_Takeoff, Fixed_Wing_Land
Heavy Plane Fixed_Wing_Takeoff, Fixed_Wing_Land
High Maneuverability Fighter
Fixed_Wing_Takeoff, Fixed_Wing_Land
GAU-8 Avenger Strafe_Ground_Target, Attack_Aircraft_with_Guns Tracks move-to-location-path-plan, move-to-waypoint-path-plan Tracks/Amphibious move-to-location-path-plan, move-to-waypoint-path-plan Wheels (off road) move-to-location-path-plan, move-to-waypoint-path-plan Wheels (road) move-to-location-path-plan, move-to-waypoint-path-plan GSh-301 Cannon Strafe_Ground_Target, Attack_Aircraft_with_Guns
AK-47 Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc
Section XIV - Appendixes
D-54 VT MAK
Table D-3: Systems and Configured Scripted Tasks, EntityLevel.sms
System Scripted Tasks
System Scripted Tasks
Throw Grenades ThrowGrenade, ThrowGrenadeTarget
M16 rifle Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc
Handheld M240B Machine Gun
Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc
M249 SAW Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc
Handheld M60 Machine Gun
Homing Torpedo Capa- bility (Forward Launched)
Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc
Delayed_homing, Delayed_homing_ASW, Launch_Torpe- do_Salvo
Flee From Explosions bhave-Flee_From_Explosion
Lifeform Suppression Suppressed_Crouch, Suppressed_Prone
M2HB Machine Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc
M203 Grenade Launcher
Fire_M203_at_Location, Fire_M203_at_Target
M230 Chain Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc M240 Machine Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc M60 Machine Gun Provide_Suppressive_Fire, Provide_Suppressive_Fire_Loc M61 Vulcan Strafe_Ground_Target, Attack_Aircraft_with_Guns
Naval Depth Charge Deployment
Naval Mine Deploy- ment
Drop_Naval_Depth_Charge, Drop_Na- val_Depth_Charge_At_Location
Drop_Naval_Mine, Drop_Naval_Mines_Along_Route
Naval Mine Sweep Naval_Mine_Sweep
Pedestrian Crowd Movement
Pedestrian Traffic Generator
Crowd_Around, Crowd_Around_Location, Crowd_In_- Front_Of, Crowd_Along_Line, Disperse_Crowd, Wander_In_Area, Protest, Protest_Along_Line
Create_Initial_Pedestrians, Create_Pedestrians, Delete_Cre- ated_Pedestrians
Periscope Raise_Periscope, Lower_Periscope
Dipping SONAR Sensor
Sonar_Dip
Sonobuoy Deployer Deploy_Sonobuoy, Deploy_Sonobuoys_Along_Route Tanker Refueling Boom Deploy_Refueling_Boom, Stow_Refueling_Boom
Mortar, 120mm weapon aggregate,
assemblies
A single 120mm mortar tube. Capable of indirect fire missions.
Active RADAR Sensor
Aerial Refueling Resupply
sensor all Allows an entity to detect other objects through RADAR. Also publishes emitter beams that represent the emissions from the sensor.
other all Gives the unit the capability to resupply aviation fuel to airborne units from an airborne unit.
122mm Howitzer weapon aggregate,
assemblies
Artillery piece capable of indirect fire missions.
152mm Howitzer Auto
weapon aggregate, assemblies
Artillery piece capable of indirect fire missions. Uses auto-loader.
155mm Howitzer weapon aggregate,
assemblies
Artillery piece capable of indirect fire missions.
Bomb, 2000lb JDAM
weapon aggregate, assemblies
A precision guided bomb. Uses GPS
Mk 45 5-inch Gun weapon aggregate,
assemblies
A naval gun capable of indirect fire operations.
9K330 Surface- to-Air Missile Launcher
weapon aggregate, assemblies
An anti-air missile. Uses radar guidance.
9P140 MRL weapon aggregate,
assemblies
Multiple Rocket Launcher System Russia
AIM-120
AMRAAM Missile
weapon aggregate, assemblies
A medium range anti-air missile. Uses radar guidance.
Communications Jammer
electron- icwarfare
all Jamming system for radios, cell phones, satellite phones, UAVs, etc.
Harpoon Antiship Missile
weapon aggregate, assemblies
A long range anti-ship missile. Radar guided.
M993 MLRS weapon aggregate,
assemblies
Torpedo, Mark 54 weapon aggregate,
assemblies
Multiple Rocket Launcher System USA
An anti-ship and anti-submarine torpedo. Can be air-dropped.
Radar Jammer electron- icwarfare
all Jamming system for acquisition and tracking/guidance radars.
Guided Bomb weapon aggregate,
assemblies
A precision guided bomb. Uses optical or other non-radar guid- ance.
Section XIV - Appendixes
D-56 VT MAK
RIM-66 SAM weapon aggregate,
assemblies
A surface to air missile. Uses radar guidance.
Sidewinder Anti- Air Missile
Stinger Anti-Air Missile
Tomahawk Cruise Missile
weapon aggregate, assemblies
weapon aggregate, assemblies
weapon aggregate, assemblies
A short range anti-air missile. Uses IR guidance.
An anti-air missile with limited altitude. Uses IR guidance.
A long range guided land attack missile. Uses primarily GPS and optical guidance.
Unguided Bomb weapon aggregate,
assemblies
A bomb intended to have effects in an area.
Torpedo, Type 40 (RPK-6 Vodopad SUBROC)
weapon aggregate, assemblies
An anti-ship and anti-submarine torpedo with SUBROC configura- tion. Can be deck-launched.
Air Defense RADAR Sensor
sensor all Allows an entity to detect aircraft through RADAR. Also publishes emitter beams that represent the emissions from the sensor.
Air-Drop Supply other all Gives the unit the capability to
resupply ground units from the air.
Active RADAR Sensor
Aircraft Aggre- gated Movement
sensor all Allows an entity to detect other objects through RADAR. Also publishes emitter beams that represent the emissions from the sensor.
aggregated aggregate Aircraft aggregated movement.
Biological Weapon weapon aggregate,
assemblies
A weapon system that create biological contamination areas.
Booby Trap Setter engineering-
object- creation
Bridge Builder engineering- object- creation
aggregate, assemblies
aggregate, assemblies
A system which provides the capability to create booby traps.
A system which provides the capability to create bridges.
Chemical Weapon weapon aggregate,
assemblies
A weapon system that create chemical contamination areas.
Ditch Digger engineering- object- creation
aggregate, assemblies
A system which provides the capability to create a ditch.
SIGINT Sensor sensor all Allows an entity to detect other
entities by their radio and RADAR emissions.
Engagement Report Generator
Engineering Object Sensor
other all Allows the entity to send engage- ment reports through its radio when it is attacking an enemy.
sensor all Allows an entity to detect engi- neering objects.
Engineering Obstacle Destroyer
Explosive Hazard and Simple Obstacle Destroyer
obstacle- destruction
obstacle- destruction
aggregate, assemblies
aggregate, assemblies
A system which provides the capability to destroy/breach engi- neering obstacles. Meant to be used by units with specialized equipment.
A system which provides the capability to destroy explosive hazards as well as destroy/breach simple obstacles.
FASCAM weapon aggregate, assemblies
Artillery used to deploy mine- fields.
Fortification Builder
engineering- object- creation
aggregate, assemblies
A system which provides the capability to construct fortifica- tions.
Ground Aggre- gated Movement
Ground Combat Behaviors
aggregated aggregate Basic movement capabilities for
any ground-based aggregated unit, both vehicle and DI.
other all Enables behaviors appropriate for ground combat units.
IFF Transponder other all Sends IFF data, when turned on.
IFF is off by default.
Infantry Aggre- gated Movement
aggregated aggregate Infantry aggregated movement.
IR Sensor sensor all Allows an entity to detect other
objects through Infrared.
Limit Entity Exis- tence
Mechanized Aggregated Movement
other all Used to control the life span of the object this system is attached to. Once it's life span is up the object is removed from the simu- lation.
aggregated aggregate Mechanized aggregated move-
ment.
Section XIV - Appendixes
D-58 VT MAK
Mine Dispenser engineering-
object- creation
aggregate, assemblies
A system which provides the capability to create minefields.
MOPP Gear other aggregate, assemblies
Equips the unit with MOPP gear which allows MOPP level transi- tions.
Motorized Aggre- gated Movement
aggregated aggregate Motorized aggregated movement.
NBC Sensor sensor all Allows an entity to detect areas
contaminated with nuclear, biological, or chemical agents.
Nuclear Weapon weapon aggregate,
assemblies
A weapon system that create nuclear contamination areas.
Obstacle Builder engineering-
object- creation
aggregate, assemblies
A system which provides the capability to construct basic obstacles.
Passive RADAR Sensor
sensor all Allows an entity to detect other objects through RADAR. No emitters are published for this sensor.
Ground Resupply other all Gives the unit the capability to
resupply units on the ground.
Riverine Aggre- gated Movement
Ship Aggregated Movement
aggregated aggregate Riverine movement system for
aggregate of one light patrol craft.
aggregated aggregate Ship movement system for aggre-
gate of one type ships.
Simple Obstacle Destroyer
obstacle- destruction
aggregate, assemblies
A system which provides the capability to destroy/breach simple obstacles. Meant to be used by units without specialized equipment.
SONAR Sensor sensor all Allows an entity to detect other
objects through SONAR.
Spot Report Generator
other all Allows the entity to send spot reports through its radio when its sensors detect other entities in the scenario.
Spot Report Receiver
Subsurface Aggregated Movement
Tank Aggregated Movement
other all Allows an entity to receive spot reports from other entities over the radio, and add these contacts to its list of known entities. By default, spot reports expire after 5 minutes.
aggregated aggregate Subsurface movement system for
AggregateSMS submarines. aggregated aggregate Tank aggregated movement.
Visual Sensor sensor all Allows an entity to detect other
objects through visible light.
Table D-5: System usage, AgregateLevel.sms
System Entities that Use System
System Entities that Use System
Mortar, 120mm AR CAV TRP US, MECH BN US solo, Mortar PLT US, Mortar SP PLT US, TANK BN RU solo, TANK BN US solo
Active RADAR Sensor
Aerial Refueling Resupply
ADA BN RU solo, EA-18G Growler, F-16C (Air Superiority - improved), F-16C (Air Superiority), F/A-18 (Ground Attack), F/A- 18 (Ship Attack), Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry, Sub, RU SSP, Lada
122mm Howitzer Artillery BTY RU, FA BN RU solo
152mm Howitzer Auto
Artillery SP BTY - NBC, Artillery SP BTY RU
155mm Howitzer Artillery SP BTY US, FA BN US solo, Artillery BTY US
Bomb, 2000lb JDAM
F/A-18 (Ground Attack)
Mk 45 5-inch Gun Ship, US DDG, Arleigh Burke
9K330 Surface- to-Air Missile Launcher
ADA BN RU solo, SAM BTY RU
9P140 MRL MRL BTY RU
AIM-120
AMRAAM Missile
Communications Jammer
F-16C (Air Superiority - improved), F-16C (Air Superiority), F/A- 18 (Ground Attack)
MI BN US solo, MI CO US, MI PLT US
Section XIV - Appendixes
D-60 VT MAK
Harpoon Antiship Missile
F/A-18 (Ship Attack), Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry
M993 MLRS MLRS BTY US
Torpedo, Mark 54 Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry Radar Jammer EA-18G Growler
Guided Bomb
RIM-66 SAM Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry
Sidewinder Anti- Air Missile
Stinger Anti-Air Missile
Tomahawk Cruise Missile
Unguided Bomb
Torpedo, Type 40 (RPK-6 Vodopad SUBROC)
Air Defense RADAR Sensor
Air-Drop Supply
Active RADAR Sensor
Aircraft Aggre- gated Movement
EA-18G Growler, F-16C (Air Superiority - improved), F-16C (Air Superiority), F/A-18 (Ground Attack), F/A-18 (Ship Attack)
ADA BN US solo, ADA BTY US, ADA PLT US
Ship, US DDG, Arleigh Burke
Sub, RU SSP, Lada
SAM BTY RU
F-16C (Air Superiority), F/A-18 (Ground Attack), F/A-18 (Ship Attack)
AIR ASLT BN US solo, Air Assault CO US, Air Attack CO US, Air Cav TRP US, AIR LIFT BN US solo, AVN SPT TROOP, Civilian
Aircraft, EA-18G Growler, F-16C (Air Superiority - improved), F- 16C (Air Superiority), F/A-18 (Ground Attack), F/A-18 (Ship Attack), AIR ATK SQDN US solo, _Air FW template, _Air RW template
Biological Weapon Artillery SP BTY - NBC
Booby Trap Setter ENG BN US solo, Eng Mob Aug CO, ENG PLT US Bridge Builder ENG BN US solo, Eng Mob Aug CO, ENG PLT US Chemical Weapon Artillery SP BTY - NBC, Artillery SP BTY RU
Ditch Digger ENG BN US solo, Eng Mob Aug CO, ENG PLT US, Mech Inf CO US
SIGINT Sensor MI BN US solo, MI CO US, MI PLT US
Engagement Report Generator
Engineering Object Sensor
Engineering Obstacle Destroyer
ADA BN RU solo, ADA BN US solo, ADA BTY US, ADA PLT US,
AIR ASLT BN US solo, Air Assault CO US, Air Attack CO US, Air Cav TRP US, AIR LIFT BN US solo, AR CAV TRP US, Artillery SP
BTY - NBC, Artillery BTY RU, Artillery SP BTY RU, Artillery SP BTY US, AVN SPT TROOP, CIV BN solo, Civilian Aircraft, Civilian CO, CSS CO, CSS PLT, EA-18G Growler, ENG BN US
solo, Eng Clearance CO, Eng Mob Aug CO, ENG PLT US, F-16C (Air Superiority - improved), F-16C (Air Superiority), FA BN RU solo, FA BN US solo, Artillery BTY US, F/A-18 (Ground Attack), F/A-18 (Ship Attack), IFV SEC US, INF BN RU solo, INF BN US
solo, MECH BN RU solo, MECH BN US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, MEDICAL BN US solo, Medical CO US, MI BN US solo, MI CO US, MLRS BTY US, Mortar PLT US, Mortar SP PLT US, MRL BTY RU, Rifle CO RU, Rifle CO US, AIR ATK SQDN US solo, SAM BTY RU, Scout Hvy CO US,
Scout Hvy PLT US, Scout Motorized CO US, Scout Motorized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry, MI PLT US, Sub, RU SSP, Lada, TANK BN RU solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US,
Weapons CO US, _Air FW template, _Air RW template, _Ground master template, _Light armor template, _Mechanized template,
_SPA template, _Tank unit template, _Towed arty template,
_Unarmored foot template, _Unarmored wheeled template
ADA BN RU solo, ADA BN US solo, ADA BTY US, ADA PLT US,
AR CAV TRP US, Artillery SP BTY - NBC, Artillery BTY RU, Artil- lery SP BTY RU, Artillery SP BTY US, CIV BN solo, Civilian CO, CSS BN US solo, CSS CO, CSS PLT, ENG BN US solo, Eng
Clearance CO, Eng Mob Aug CO, ENG PLT US, FA BN RU solo, FA BN US solo, Artillery BTY US, IFV SEC US, INF BN RU solo, INF BN US solo, MECH BN RU solo, MECH BN US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, MEDICAL BN US solo, Medical CO US, MI BN US solo, MI CO US, MLRS BTY US,
Mortar PLT US, Mortar SP PLT US, MRL BTY RU, Rifle CO RU, Rifle CO US, SAM BTY RU, Scout Hvy CO US, Scout Hvy PLT US, Scout Motorized CO US, Scout Motorized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry, MI PLT US, Sub, RU SSP, Lada, TANK BN RU solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US, Weapons
CO US, _Ground master template, _Light armor template,
_Mechanized template, _SPA template, _Tank unit template,
_Towed arty template, _Unarmored foot template, _Unarmored wheeled template
ENG BN US solo, Eng Mob Aug CO, ENG PLT US
Section XIV - Appendixes
D-62 VT MAK
Explosive Hazard and Simple Obstacle Destroyer
Eng Clearance CO
FASCAM Artillery BTY RU, Artillery SP BTY US, Artillery BTY US
Fortification Builder
Ground Aggre- gated Movement
Ground Combat Behaviors
ENG BN US solo, Eng Mob Aug CO, ENG PLT US
IFF Transponder AIR ASLT BN US solo, Air Assault CO US, Air Attack CO US, Air Cav TRP US, AIR LIFT BN US solo, AVN SPT TROOP, EA-18G
Growler, F-16C (Air Superiority), F/A-18 (Ground Attack), F/A- 18 (Ship Attack), AIR ATK SQDN US solo, _Air FW template
Infantry Aggre- gated Movement
CIV BN solo, Civilian CO, INF BN RU solo, INF BN US solo, Mortar PLT US, Rifle CO RU, Rifle CO US, _Unarmored foot template
IR Sensor ADA BN US solo, ADA BTY US, ADA PLT US, Air Attack CO US, Air Cav TRP US, AIR LIFT BN US solo, AR CAV TRP US, AVN SPT TROOP, AIR ATK SQDN US solo, TANK BN US solo, Tank CO US, TANK PLT US, TANK SEC US
Limit Entity Exis- tence
Mechanized Aggregated Movement
ADA BN RU solo, Artillery SP BTY - NBC, Artillery SP BTY RU, Artillery SP BTY US, ENG BN US solo, Eng Clearance CO, Eng Mob Aug CO, ENG PLT US, IFV SEC US, MECH BN RU solo,
MECH BN US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, Mortar SP PLT US, SAM BTY RU, Scout Hvy CO US,
Scout Hvy PLT US, _Light armor template, _Mechanized template, _SPA template
Mine Dispenser ENG BN US solo, Eng Mob Aug CO, ENG PLT US
MOPP Gear ADA BN RU solo, ADA BN US solo, ADA BTY US, ADA PLT US,
AR CAV TRP US, Artillery SP BTY - NBC, Artillery BTY RU, Artil- lery SP BTY RU, Artillery SP BTY US, CSS BN US solo, CSS CO, CSS PLT, ENG BN US solo, Eng Clearance CO, Eng Mob Aug CO, ENG PLT US, FA BN RU solo, FA BN US solo, Artillery BTY US, IFV SEC US, INF BN RU solo, INF BN US solo, MECH BN RU
solo, MECH BN US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, MEDICAL BN US solo, Medical CO US, MI BN
US solo, MI CO US, MLRS BTY US, Mortar PLT US, Mortar SP PLT US, MRL BTY RU, Rifle CO RU, Rifle CO US, SAM BTY RU,
Scout Hvy CO US, Scout Hvy PLT US, Scout Motorized CO US, Scout Motorized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, MI PLT US, TANK BN RU
solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US, Weapons CO US, _Ground master template,
_Light armor template, _Mechanized template, _SPA template,
_Tank unit template, _Towed arty template, _Unarmored foot template, _Unarmored wheeled template
Motorized Aggre- gated Movement
ADA BN US solo, ADA BTY US, ADA PLT US, Artillery BTY RU, CSS BN US solo, CSS CO, CSS PLT, FA BN RU solo, FA BN US
solo, Artillery BTY US, MEDICAL BN US solo, Medical CO US, MI BN US solo, MI CO US, MLRS BTY US, MRL BTY RU, Scout
Motorized CO US, Scout Motorized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, MI PLT US,
Weapons CO US, _Towed arty template, _Unarmored wheeled template
NBC Sensor ADA BN RU solo, ADA BN US solo, ADA BTY US, ADA PLT US,
AR CAV TRP US, Artillery SP BTY - NBC, Artillery BTY RU, Artil- lery SP BTY RU, Artillery SP BTY US, CIV BN solo, Civilian CO, CSS BN US solo, CSS CO, CSS PLT, ENG BN US solo, Eng
Clearance CO, Eng Mob Aug CO, ENG PLT US, FA BN RU solo, FA BN US solo, Artillery BTY US, IFV SEC US, INF BN RU solo, INF BN US solo, MECH BN RU solo, MECH BN US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, MEDICAL BN US solo, Medical CO US, MI BN US solo, MI CO US, MLRS BTY US,
Mortar PLT US, Mortar SP PLT US, MRL BTY RU, Rifle CO RU, Rifle CO US, SAM BTY RU, Scout Hvy CO US, Scout Hvy PLT US, Scout Motorized CO US, Scout Motorized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, MI PLT US, TANK BN RU solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US, Weapons CO US,
_Ground master template, _Light armor template, _Mechanized template, _SPA template, _Tank unit template, _Towed arty template, _Unarmored foot template, _Unarmored wheeled template
Nuclear Weapon Artillery SP BTY - NBC
Obstacle Builder ENG BN US solo, Eng Mob Aug CO, ENG PLT US
Section XIV - Appendixes
D-64 VT MAK
Passive RADAR Sensor
Ground Resupply CSS BN US solo, CSS CO, CSS PLT Riverine Aggre-
gated Movement
Ship Aggregated Movement
Simple Obstacle Destroyer
Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry
ADA BN RU solo, ADA BN US solo, ADA BTY US, ADA PLT US,
AR CAV TRP US, Artillery SP BTY - NBC, Artillery BTY RU, Artil- lery SP BTY RU, Artillery SP BTY US, CIV BN solo, Civilian CO, FA BN RU solo, FA BN US solo, Artillery BTY US, IFV SEC US, INF BN RU solo, INF BN US solo, MECH BN RU solo, MECH BN
US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, MEDICAL BN US solo, Medical CO US, MI BN US solo, MI CO US, MLRS BTY US, Mortar PLT US, Mortar SP PLT US, MRL
BTY RU, Rifle CO RU, Rifle CO US, SAM BTY RU, Scout Hvy CO US, Scout Hvy PLT US, Scout Motorized CO US, Scout Motor- ized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, MI PLT US, TANK BN RU solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US,
Weapons CO US, _Ground master template, _Light armor template, _Mechanized template, _SPA template, _Tank unit template, _Towed arty template, _Unarmored foot template,
_Unarmored wheeled template
SONAR Sensor Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry, Sub, RU SSP, Lada
Spot Report Generator
Spot Report Receiver
ADA BN RU solo, ADA BN US solo, ADA BTY US, ADA PLT US,
AIR ASLT BN US solo, Air Assault CO US, Air Attack CO US, Air Cav TRP US, AIR LIFT BN US solo, AR CAV TRP US, Artillery SP
BTY - NBC, Artillery BTY RU, Artillery SP BTY RU, Artillery SP BTY US, AVN SPT TROOP, CIV BN solo, Civilian Aircraft, Civilian CO, CSS CO, CSS PLT, EA-18G Growler, ENG BN US
solo, Eng Clearance CO, Eng Mob Aug CO, ENG PLT US, F-16C (Air Superiority - improved), F-16C (Air Superiority), FA BN RU solo, FA BN US solo, Artillery BTY US, F/A-18 (Ground Attack), F/A-18 (Ship Attack), IFV SEC US, INF BN RU solo, INF BN US
solo, MECH BN RU solo, MECH BN US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, MEDICAL BN US solo, Medical CO US, MI BN US solo, MI CO US, MLRS BTY US, Mortar PLT US, Mortar SP PLT US, MRL BTY RU, Rifle CO RU, Rifle CO US, AIR ATK SQDN US solo, SAM BTY RU, Scout Hvy CO US,
Scout Hvy PLT US, Scout Motorized CO US, Scout Motorized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry, MI PLT US, Sub, RU SSP, Lada, TANK BN RU solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US,
Weapons CO US, _Air FW template, _Air RW template, _Ground master template, _Light armor template, _Mechanized template,
_SPA template, _Tank unit template, _Towed arty template,
_Unarmored foot template, _Unarmored wheeled template
ADA BN RU solo, ADA BN US solo, ADA BTY US, ADA PLT US,
AIR ASLT BN US solo, Air Assault CO US, Air Attack CO US, Air Cav TRP US, AIR LIFT BN US solo, AR CAV TRP US, Artillery SP
BTY - NBC, Artillery BTY RU, Artillery SP BTY RU, Artillery SP BTY US, AVN SPT TROOP, CIV BN solo, Civilian Aircraft, Civilian CO, EA-18G Growler, ENG BN US solo, Eng Clearance CO, Eng Mob Aug CO, ENG PLT US, F-16C (Air Superiority - improved), F-16C (Air Superiority), FA BN RU solo, FA BN US solo, Artillery BTY US, F/A-18 (Ground Attack), F/A-18 (Ship Attack), IFV SEC US, INF BN RU solo, INF BN US solo, MECH
BN RU solo, MECH BN US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, MEDICAL BN US solo, Medical CO US, MI
BN US solo, MI CO US, MLRS BTY US, Mortar PLT US, Mortar SP PLT US, MRL BTY RU, Rifle CO RU, Rifle CO US, AIR ATK
SQDN US solo, SAM BTY RU, Scout Hvy CO US, Scout Hvy PLT US, Scout Motorized CO US, Scout Motorized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry, MI PLT US, Sub, RU SSP, Lada, TANK BN RU solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US,
Weapons CO US, _Air FW template, _Air RW template, _Ground master template, _Light armor template, _Mechanized template,
_SPA template, _Tank unit template, _Towed arty template,
_Unarmored foot template, _Unarmored wheeled template
Section XIV - Appendixes
D-66 VT MAK
Subsurface Aggregated Movement
Tank Aggregated Movement
Sub, RU SSP, Lada
AR CAV TRP US, TANK BN RU solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US, _Tank unit
template
Visual Sensor ADA BN RU solo, ADA BN US solo, ADA BTY US, ADA PLT US, AIR ASLT BN US solo, Air Assault CO US, Air Attack CO US, Air Cav TRP US, AIR LIFT BN US solo, AR CAV TRP US, Artillery SP
BTY - NBC, Artillery BTY RU, Artillery SP BTY RU, Artillery SP BTY US, AVN SPT TROOP, CIV BN solo, Civilian CO, CSS BN
US solo, CSS CO, CSS PLT, EA-18G Growler, ENG BN US solo, Eng Clearance CO, Eng Mob Aug CO, ENG PLT US, F-16C (Air Superiority - improved), F-16C (Air Superiority), FA BN RU solo, FA BN US solo, Artillery BTY US, F/A-18 (Ground Attack), F/A- 18 (Ship Attack), IFV SEC US, INF BN RU solo, INF BN US solo, MECH BN RU solo, MECH BN US solo, Mech Inf CO RU, Mech Inf CO US, MECH PLT US, MEDICAL BN US solo, Medical CO US, MI BN US solo, MI CO US, MLRS BTY US, Mortar PLT US, Mortar SP PLT US, MRL BTY RU, Rifle CO RU, Rifle CO US, AIR
ATK SQDN US solo, SAM BTY RU, Scout Hvy CO US, Scout Hvy PLT US, Scout Motorized CO US, Scout Motorized PLT US, Scout Motorized SQD US MK19, Scout Motorized SQD US 50BMG, Ship, US DDG, Arleigh Burke, Ship, US FFG, Perry, MI PLT US, Sub, RU SSP, Lada, TANK BN RU solo, TANK BN US solo, Tank CO RU, Tank CO US, TANK PLT US, TANK SEC US,
Weapons CO US, _Air FW template, _Air RW template, _Ground master template, _Light armor template, _Mechanized template,
_SPA template, _Tank unit template, _Towed arty template,
_Unarmored foot template, _Unarmored wheeled template
Table D-6: Systems and Configured Scripted Tasks, AggregateLevel.sms
System Scripted Tasks
System Scripted Tasks
Mortar, 120mm Indirect_Fire, Limited_Munition_Attack
Aerial Refueling Resupply
Provide_Supplies, Change_Supplying_Command
122mm Howitzer Indirect_Fire, Limited_Munition_Attack
152mm Howitzer Auto
Indirect_Fire, Limited_Munition_Attack
155mm Howitzer Indirect_Fire, Limited_Munition_Attack
Bomb, 2000lb JDAM
Bomb_Location, Limited_Munition_Attack, Ground_Attack
Mk 45 5-inch Gun Indirect_Fire, Limited_Munition_Attack
Table D-6: Systems and Configured Scripted Tasks, AggregateLevel.sms
System Scripted Tasks
System Scripted Tasks
9K330 Surface-to- Air Missile Launcher
Limited_Munition_Attack, Attack_with_AntiAir_Missile, Auto- matic_Air_Defense, React_To_Air_Threats
9P140 MRL Indirect_Fire, Limited_Munition_Attack
AIM-120
AMRAAM Missile
Communications Jammer
Harpoon Antiship Missile
Limited_Munition_Attack, Attack_with_AntiAir_Missile, Auto- matic_Air_Defense, React_To_Air_Threats
EW_Attack, Activate_Jammer, Deactivate_Jammer
Limited_Munition_Attack, Attack_with_Antiship_Missile, React_To_Naval_Threats_Missile
M993 MLRS Indirect_Fire, Limited_Munition_Attack
Torpedo, Mark 54 Limited_Munition_Attack, Attack_with_Torpedo, React_To_Na- val_Threats_Torpedo
Radar Jammer EW_Attack, Activate_Jammer, Deactivate_Jammer Guided Bomb Bomb_Location, Limited_Munition_Attack, Ground_Attack
RIM-66 SAM Limited_Munition_Attack, Attack_with_AntiAir_Missile, Auto- matic_Air_Defense, React_To_Air_Threats
Sidewinder Anti-Air Missile
Stinger Anti-Air Missile
Tomahawk Cruise Missile
Limited_Munition_Attack, Attack_with_AntiAir_Missile, React_To_Air_Threats
Limited_Munition_Attack, Attack_with_AntiAir_Missile, Auto- matic_Air_Defense, React_To_Air_Threats
Limited_Munition_Attack, Attack_with_Land-Attack_Missile
Unguided Bomb Bomb_Location, Limited_Munition_Attack, Ground_Attack
Torpedo, Type 40 (RPK-6 Vodopad SUBROC)
Limited_Munition_Attack, Attack_with_Torpedo, React_To_Na- val_Threats_Torpedo
Air-Drop Supply Provide_Supplies, Change_Supplying_Command
Aircraft Aggre- gated Movement
Maximum_Speed_Modifier
Biological Weapon Biological_Attack, NBC_Attack
Booby Trap Setter Create_Booby_Trap, Improve_Booby_Trap Bridge Builder Construct_Bridge, Improve_Bridge Chemical Weapon Chemical_Attack, NBC_Attack
Ditch Digger Create_Anti-Tank_Ditch, Improve_Ditch, Create_Dry_Gap
Engineering Obstacle Destroyer
Destroy_Obstacle, Destroy_Fortification, Destroy_Ditch, Destroy_Bridge, Destroy_Explosive, Breach_Obstacles, Improve_Breach
Section XIV - Appendixes
D-68 VT MAK
Table D-6: Systems and Configured Scripted Tasks, AggregateLevel.sms
System Scripted Tasks
System Scripted Tasks
Explosive Hazard and Simple Obstacle Destroyer
Destroy_Explosive_Hazard, Destroy_Obstacle, Breach_Obsta- cles, Improve_Breach
FASCAM FASCAM
Fortification Builder Construct_Barricade, Improve_Fortification, Construct_Forti- fied_Line, Construct_Fortified_Area, Construct_Strong_Point
Ground Aggre- gated Movement
Ground Combat Behaviors
Infantry Aggre- gated Movement
Mechanized Aggre- gated Movement
Maximum_Speed_Modifier, Halt_Movement, Move_To_Loca- tion_Plan_Path, Move_To_Waypoint_Plan_Path
Attack_Target
Maximum_Speed_Modifier, Halt_Movement, Move_To_Loca- tion_Plan_Path, Move_To_Waypoint_Plan_Path
Maximum_Speed_Modifier, Halt_Movement, Move_To_Loca- tion_Plan_Path, Move_To_Waypoint_Plan_Path
Mine Dispenser Create_Minefield MOPP Gear Change_MOPP_Level
Motorized Aggre- gated Movement
Maximum_Speed_Modifier, Halt_Movement, Move_To_Loca- tion_Plan_Path, Move_To_Waypoint_Plan_Path
Nuclear Weapon Nuclear_Attack, NBC_Attack
Obstacle Builder Construct_Abatis, Improve_Obstacle, Construct_Barbed_Wire, Construct_Berm
Ground Resupply Provide_Supplies, Change_Supplying_Command
Riverine Aggre- gated Movement
Ship Aggregated Movement
Simple Obstacle Destroyer
Subsurface Aggre- gated Movement
Tank Aggregated Movement
Maximum_Speed_Modifier, Halt_Movement, Move_To_Loca- tion_Plan_Path, Move_To_Waypoint_Plan_Path
Maximum_Speed_Modifier, Halt_Movement, Move_To_Loca- tion_Plan_Path, Move_To_Waypoint_Plan_Path
Destroy_Obstacle, Breach_Obstacles, Improve_Breach
Maximum_Speed_Modifier, Halt_Movement, Move_To_Loca- tion_Plan_Path, Move_To_Waypoint_Plan_Path
Maximum_Speed_Modifier, Halt_Movement, Move_To_Loca- tion_Plan_Path, Move_To_Waypoint_Plan_Path
Section XIV - Appendixes
VT MAK
This glossary defines terms used in MAK product documentation.
absolute dead reckoning
A method of dead-reckoning in which an application uses the time stamps contained within state updates if the sender is using absolute time stamping. Contrast with rela- tive dead reckoning.
aggregate
The combination of individual entities, aggregates, or both into a single object. For example, an organizational group such as a platoon.
API
Application Programming Interface.
articulated part
A part of an entity that is capable of movement relative to the entity, such as a turret or gun.
attached part
An object that is attached to another object, such as a rocket attached to a jet.
body coordinate frame
A coordinate framework centered on an entity. To represent the orientation of an entity, an application uses Euler angles or a rotation matrix that rotates from a reference frame to the body coordinate frame.
channel
A channel renders the view of an observer in a 3D visualization application.
clipping
A feature that prevents the display of terrain and objects or parts of objects, that are closer than or farther than specific distances from the observer.
clipping planes
The range of distances from the observer (near clipping and far clipping) in which an application clips objects.
culling
The process of discarding database objects which are not within view, and therefore need not be rendered and displayed.
Cartesian coordinates
A system for indicating location by means of three planes intersecting at right angles to one another at the origin.
The set of HLA services used to specify the routing of data between publishers and subscribers. DDM adds greater control over the Declaration Management (DM) services that only specify filtering based on the class of the data (e.g., ground vehicle versus aircraft). DDM uses the data content to express regions of interest and regions of affect whose overlap establish a communication channel. An example is geographic filtering where a publisher indicates a region around the entity or effect and a subscriber indicates a region expressing its sensor range.
A process by which an application calculates the expected location of an entity during periods between state updates, based on velocity, acceleration, and rotational velocity.
DDM
Data Distribution Management.
Defense Modeling and Simulation Office
The former name of the executive secretariat for the Executive Council on Modeling and Simulation (EXCIMS), which provided a full-time focal point for information concerning Department of Defense modeling and simulation (M&S) activities.
Renamed Modeling and Simulation Coordination Office. Currently the MSCO promulgates M&S policy, initiatives, and guidance to promote cooperation among DoD components to maximize efficiency and effectiveness.
Distributed Interactive Simulation.
DIS data packets
See Protocol Data Unit.
display engine
An object in an application that can render 3D data.
Distributed Interactive Simulation
The DIS protocol is a set of standards that govern how participating applications share information about the virtual world. The protocol specifies a set of packets, called protocol data units (PDUs), that communicate this information. Each PDU identifies the sender and contains other information depending on the PDU type. The DIS protocol also specifies when and how frequently PDUs are sent.
The DIS protocol has been superseded by the High-Level Architecture for use by the Department of Defense.
DMSO
See Defense Modeling and Simulation Office.
element definition
In VR-Forces and VR-Vantage, an element definition specifies all of the visualizers that control the various aspects of visualizing a scene element. For example, an element defi- nition includes the main model or military symbology, trailing effects, cockpit displays, and so on.
emitter
entity
A simulated device on an entity that emits electromagnetic radiation, for example, radar.
An element in a simulation, such as a vehicle or a person, that is represented in the simulation through the issuance of state messages.
entity maintenance
A process by which the MAK Data Logger compensates for discontinuities following a time jump. The Logger sends out interim state messages for entities that were present before the time jump so that they do not time out before the next update message arrives.
entity-type
A list of seven components as specified by the DIS protocol and the HLA RPR FOM. If none of the seven components contains a wildcard (-1) value, then the entity type refers to a specific, narrowly-defined entity. If some components contain a wildcard, then the entity type refers to a class of entities. A larger number of wildcards indicates a broader, more general class.
The components of an entity-type are:
Entity kind
Domain
Country
Category
Subcategory
Specific
Extra.
environmental process
According to the IEEE 1278.1a specification (DIS), environmental process PDUs communicate simple environment variables, small scale environmental updates, and embedded processes.
Euler angles
A set of three angles used to describe the orientation of an entity as a set of three succes- sive rotations about three different orthogonal axes (x, y, and z). These angles specify successive rotations needed to transform from a reference coordinate system to the entity’s body coordinate system.
event
exercise
An interaction between objects or between an object and the terrain, such as firing of a munition, or a collision of entities.
The DIS term for a one or more interacting simulation applications. Compare to feder- ation execution in HLA.
exercise connection
The object (DtExerciseConn) through which a VR-Link application connects to the network. State messages are sent through the exercise connection and information about remote entities is received through the exercise connection. (All MAK products are VR-Link applications.)
exercise ID
A numeric identification for a DIS simulation exercise.
FED file
Federation Execution Data file. The Federation Execution Data is the subset of FOM data needed and read by the RTI. VR-Link applications also read the FED file.
federate
A connection to the RTI. Typically a single simulation application can be thought of as a federate.
federation
A group of HLA federates capable of playing in the same federation execution.
Defines the data content of a federation execution.
The federation execution represents the actual operation, over time, of a subset of the federates and the RTI initialization data taken from a particular federation. A federa- tion execution is the logical equivalent of a DIS simulation exercise.
field of view
Controls the perspective of the observer.
A wide field of view creates an effect like that of a wide-angle camera lens. Objects appear smaller and farther away from the observer, since the observer coverage spans a wider area. Depth become exaggerated.
A narrow field of view creates an effect like that of a telephoto lens. Objects appear larger and closer to the observer, and the overall scene depth appears flattened. The distances between objects appears compressed.
filter range
A setting that prevents distant entities from being processed while allowing distant terrain to appear normally.
See Federation Object Model.
FOM Module
In HLA Evolved, defines additional modular data content for a federation execution, usually extensions to an existing FOM. (Also supported by the HLA 1.3 and HLA 1516 versions of the MAK RTI. Per the HLA Evolved interface specification:
“A partial FOM (containing some or all OMT tables) that specifies a modular compo- nent of a FOM. A FOM module may contain classes not inherent to it but upon which the FOM module depends, i.e., superclasses to the modular components. These super- classes will be included in the FOM module either as complete or scaffolding defini- tions.”
frame rate
The rate at which the application displays updated images.
A process by which the a 3D visualization application keeps an entity anchored to the surface of its terrain database, regardless of the altitude data contained in its entity state message.
geocentric coordinates
A coordinate system calculated with respect to the earth’s center. The origin of the geocentric coordinate system is the center of the earth. The positive X-axis passes through the prime meridian at the equator; the positive Y-axis passes through 90 degrees east longitude at the equator; and the positive Z-axis passes though the north pole.
geodetic coordinates
A coordinate system in which position is determined relative to a reference ellipsoid, such as the surface of the earth at sea level. In MAK applications, geodetic coordinates consist of latitude and longitude in radians, and altitude in meters above the reference ellipsoid.
gridded data
Data that has been processed in a rectangular array of points, in X, Y or latitude/longi- tude, at which single data values define a two dimensional function. According to the IEEE 1278.1a specification, gridded data transmits information about large-scale or high-fidelity spatially and temporally varying ambient fields and about environmental processes and features.
guise
An alternative entity type used to display an object depending on the force ID. For example, a tank could look like an M1A1 to friendly forces and a T72 to hostile forces.
head-up display
A set of indicators and readouts superimposed onto a graphics display. Also called an overlay.
heartbeat
In DIS, the frequency with which current PDUs are sent to the network regardless of whether or not the entity’s state has changed.
The High Level Architecture (HLA) for simulations is a U. S. Department of Defense (DOD)-wide initiative to provide an architecture to support interoperability and reuse of simulations. The HLA supersedes DIS for the DOD.
See High-Level Architecture.
A message describing a simulation event. An interaction describes an event, it does not update an object’s state.
Logger control PDUs
A set of DIS PDUs or HLA interactions that let you control the MAK Logger remotely.
logical range
A suite of TENA Resources, sharing a common object model, that work together for a given range event. Similar in concept to the HLA Federation.
The libraries on a computer that implement an RTI. A federate communicates with the HLA network through the LRC.
LRC
See Local RTI Component.
An adaptation of the Lisp language used in configuration files for MAK products.
A general term used to refer to DIS PDUs and HLA interactions and state updates. In TENA, a message is similar to an HLA interaction.
MIM
The MOM & Initialization Module (MIM) allows for extensions to be made to the HLA standard MOM. It is a subset of the FOM that contains OMT tables that describe the HLA MOM. The MIM also contains additional predefined HLA constructs such as object and interaction roots, data types, transportation types and dimensions. HLA specifies a standard MIM that is incorporated into all FDDs auto- matically by the RTI. The standard MIM can be replaced with a user-supplied MIM containing the standard MIM plus extensions.
model definition
In VR-Forces and VR-Vantage, a model definition specifies the 3D model and other basic attributes of a model. It is referenced by an element definition.
Modeling and Simulation Coordination Office
The executive secretariat for the Executive Council on Modeling and Simulation (EXCIMS), which provided a full-time focal point for information concerning Depart- ment of Defense modeling and simulation (M&S) activities. The MSCO promulgates M&S policy, initiatives, and guidance to promote cooperation among DoD compo- nents to maximize efficiency and effectiveness. (Formerly DMSO)
MSCO
MTL
Modeling and Simulation Coordination Office. (Formerly DMSO.)
See MÄK Technologies Lisp.
orientation clamping
object
An element in a simulation that has persistence, as opposed to an interaction, which is a transient element.
object handle
An integer that an application uses to identify a particular object in RTI service calls. An object handle is meaningful only to a particular federate. The same object can be known to different federates by different object handles.
object name
A character string that can be used to identify an object. In HLA, the object name is known to the RTI, and the RTI provides functions to find out an object’s name, given its handle, and vice versa. Object names can be chosen by applications that register the objects with the RTI, however if you do not want to choose names for objects, the RTI will assign names for you.
observer
In MAK 3D applications, the point of view into the scene. (Called the eyepoint in MAK Stealth 6.x and earlier.)
See Protocol Data Unit.
A unit of data message (packet) that is passed on a network between DIS simulation applications.
radio transmitter
A simulated device on an entity, capable of transmitting radio communications.
radio receiver
A simulated device on an entity, capable of receiving radio communications.
Realtime Platform Reference FOM
An HLA reference FOM based on the DIS protocol.
recording
A Data Logger file that stores a history of the interactions in a simulation for playback.
reflected entity list
A list of entities simulated by remote applications (federates in HLA) and about which the local simulation has received information over the network.
reference FOM
A FOM designed to be used as a whole, or with modification, by a wide variety of similar federation executions.
A method of dead reckoning in which an application approximates the location of an object based on the local time of receipt of the last state update message.
remote display engine
A display engine running in an application that is separate from the master application, and which is controlled by the master application.
RID file
See RTI Initialization Data.
The initialization data required by the RTI for operation.
Data required by an RTI during initialization, independent of the FOM being used. RID data is usually dependent on a specific implementation of the RTI.
RPR FOM
See Realtime Platform Reference FOM.
See Run-Time Infrastructure.
A library and other supporting software that implements the HLA interface specifica- tion. All federates communicate with one another in an HLA environment through RTI functions.
scene element
In VR-Vantage and VR-Forces, any object that is rendered in the scene, such as an entity model, interaction, or tactical graphic.
Simulation Interoperability Standards Organization
A group that seeks to promote modeling and simulation interoperability and reuse for the benefit of diverse M&S communities, including developers, procurers, and users, world-wide.
simulation time
In VR-Forces, simulation time is used in dead-reckoning of remote entities and thresh- olding of local entities. Typically, simulation time is set once during each iteration of the application's main simulation loop so that all entities are dead-reckoned based on the same value of current time.
SISO
See Simulation Interoperability Standards Organization.
smooth period
The period of time over which trajectory smoothing takes place.
smoothing
A method of ensuring that transitions from an entity’s dead-reckoned position to its actual position are not so abrupt as to be visually disconcerting.
state
tape
The current status of an object, including location, direction of movement, extent of damage, and so on.
An alternative term for a Logger recording. Not a physical magnetic tape.
terrain following
In a 3D visualization application, causes the observer (eyepoint) to maintain a constant distance above the terrain surface. The observer’s height changes in tandem with the peaks and valleys as it passes over the geography.
timeout
The period of time in which an application continues to display an entity after that entity’s update messages have stopped appearing on the network. Time-outs are usually not used in HLA because there is no set frequency (no heartbeat) for transmitting messages.
timescale
A factor by which time is accelerated or slowed during playback of a Data Logger recording.
topographic coordinates
A right-handed Cartesian coordinate system whose X-Y plane is tangent to the earth's surface at the origin, with the positive X axis pointing north, the positive Y axis pointing east, and the positive Z axis pointing down. There are an infinite number of topographic coordinate systems – one for each point on the earth's surface.
topographic coordinate frame
A coordinate frame in the context of the terrain.
A method used by to smooth positional discontinuities that could occur when new state updates arrive.
UDP port
A network channel through which an application sends and receives data for DIS exer- cises.
In general, a non-cartesian coordinate system in which the X, Y, and Z correspond to easting (nearly east), northing (nearly north), and height above an ellipsoid that approx- imates the surface of the earth.
UTM
See Universal Transverse Mercator.
view control messages
A set of programmatic messages that let you control the view in VR-Vantage applica- tions remotely.
--enableVSync command-line option 6-19
--noAppDataEntityTypeMap command-line option 82-9
-- command-line option 5-3, 5-12, 5-14, 60-4 Simulation Object Editor 64-4
--additionalSystemScriptsDirectory command- line option 5-9
--alphaBits command-line option 5-3, 6-14
--antiAliasing command-line option 5-3, 6-14
--appDataDir command-line option 5-3, 5-9 Simulation Object Editor 64-4
--appIdRange command-line option 5-8, 5-9
--appNumber command-line option 5-7, 5-8, 5-9
--autoConnect command-line option 5-3
--backend command-line option 5-14
--col command-line option 60-4
--config command-line option 5-14
--countryCodesMappingFile command-line option 5-10
--daemon command-line option 5-10
--dataDir command-line option 5-3, 5-10 Simulation Object Editor 64-4
--defaultObjectTimeout command-line option 5- 8, 5-10
--defaultSimulationModelSet command-line option 5-3
--depthBits command-line option 6-14
--depthBuffer command-line option 5-3
--destAddrString command-line option 5-8, 5-13
--deviceAddress command-line option 5-8, 5-13
--diGuyAnimationsFile command-line option 5- 10
--diGuyCharacerDataFile command-line option 5-10
--disableCallbackQueue command-line option 5- 10
--disableDynamicTerrain command-line option 5- 3
--disableKDTrees command-line option 5-5
--disableParallelTick command-line option 5-10
--disPort command-line option 5-9, 5-13
--dispSetting command-line option 5-3
--disVersion command-line option 5-8, 5-13, 5-21
--doNotCheckPluginVersions command-line option 5-3
--doNotLoadVrfPlugins command-line option 5- 3, 5-10
--enableChannel command-line option 5-10
--enableLogFileTimestamps command-line option 5-3
--enableVSync command-line option 5-4
--encryptImages command-line option 60-4
--entDispSetting command-line option 5-4
--entityDefsDir command-line option 5-4, 81-34
--entTypeMap command-line option 5-4
--envSetting command-line option 5-4
--execname command-line option 5-8, 5-13
--exerciseId command-line option 5-9, 5-13
--extendLevelZero command-line option 60-4
--extraArgs command-line option 5-3
--factoryRootDir command-line option 5-4
--federateName command-line option 5-8, 5-12
--federateType command-line option 5-8, 5-13
--fedFileName command-line option 5-7, 5-12
--file command-line option 60-4
--fileNotifyLevel command-line option 5-10
--fileTransporterReceivePort command-line option 5-4, 5-8
--fomMapperInitData command-line option 5-7, 5-12
--fomMapperLib command-line option 5-7, 5-12
--fomModules command-line option 5-8, 5-12
--forceTextShaping command-line option 5-4
--fowPerspective command-line option 5-4
--frameRate command-line option 5-4
--frontend command-line option 5-14
--frontEndPID command-line option 5-9
--fullScreen command-line option 5-4, 78-9
--fullyLoadTerrain command-line option 5-10
--generateFiles command-line option 60-5
--gui command-line option 5-4, 79-2
--guiArgs command-line option 5-14
--help command-line option 5-4, 60-5 Simulation Object Editor 64-5
--highestPriority command-line option 5-4
--hla13 command-line option 5-4
--hla1516 command-line option 5-4
--hla1516e command-line option 5-5
--hostAddressString command-line option 5-8, 5-
--ignore_rest command-line option 5-3, 5-12, 60-
--ignoreZoomForSpeedtreeLod command-line option 5-7
--launcherLocation command-line option, Simulation Object Editor 64-5
--layoutSettingsFile command-line option 5-5 Simulation Object Editor 64-5
--level command-line option 60-5
--loadObservers command-line option 5-5
--loadPlugin command-line option 5-5, 5-10, 5-
--loadSimulationObjectGroup command-line option 5-5
--locale command-line option 5-4, 5-14 Simulation Object Editor 64-5
--localSettingsDesignator command-line option 5- 8, 5-13
--logFileName command-line option 5-5, 5-10
--mcastTtl command-line option 5-9, 5-13
--mergeEntityTypeMap command-line option 5-5
--mergeHierarchyEntityDef command-line option 5-5, 81-34
--mergeHierarchyTacticalGraphicsDef command- line option 5-5, 81-34
--mergeHierarchyUnitDef command-line option 5-5, 81-34
--mergeLeafEntityDef command-line option 5-5, 81-34
--mergeLeafTacticalGraphicsDef command-line option 5-6, 81-34
--mergeLeafUnitDef command-line option 5-6, 81-34
--mergeModelDefs command-line option 5-6, 81-
--mergeTacticalGraphicsTypeMap command-line option 5-6
--mergeUnitTypeMap command-line option 5-6
--mimModule command-line option 5-12
--missing command-line option 60-5
--msdlSIDCMappingFile command-line option 5- 11
--multicastAddresses command-line option 5-9, 5-
--noAppDataEntityDefs command-line option 5- 6, 81-34
--noAppDataEntityTypeMap command-line option 5-6
--noAppDataModelDefs command-line option 5- 6, 81-19
--noAppDataTacticalGraphicsDefs command-line option 5-6, 81-34
--noAppDataTacticalGraphicsTypeMap command-line option 5-6
--noAppDataUnitDefs command-line option 5-6, 81-34
--nonVrfObjectsUUIDScheme command-line option 5-6, 5-11
--noRtiCompilerCheck command-line option 5- 12
--notifyLevel command-line option 5-6, 5-11
--numCallbackThreads command-line option 5- 11
--opdEditorLocation command-line option, Simulation Object Editor 64-5
--outputLogFile command-line option 5-11
--plugin command-line option 5-6
--pseudoFullScreen command-line option 5-7, 78-
--publishMftOnly command-line option 60-5
--recvBufferSize command-line option 5-9, 5-13
--regenerateAll command-line option 60-4
--row command-line option 60-6
--rprFomRevision command-line option 5-8, 5-13
--rprFomVersion command-line option 5-8, 5-13
--scenarioFile command-line option 5-7
--searchDir command-line option 60-5
--sendBufferSize command-line option 5-9, 5-13
--sessionId command-line option 5-8, 5-9
--setMainThreadToHighPriority command-line option 5-11
--settingsDirectory command-line option, Simulation Object Editor 64-5
--settingsFile command-line option, vrfSim 5-10
--showConsole command-line option 5-3 Simulation Object Editor 64-5
--simArgs command-line option 5-14
--simulationModelSet command-line option 5-11
--siteId command-line option 5-8, 5-9
--smsFile command-line option, Simulation Object Editor 64-5
--startMinimized command-line option 5-11
--stealth command-line option 5-7
--stencilBits command-line option 5-7, 6-14
--subDir command-line option 60-5
--subnetMask command-line option 5-9, 5-13
--suppressHatIntersectOnAttach command-line option 5-7, 50-6
--suppressSelfReflect command-line option 5-13
--synchronizeOcean command-line option 5-6
--targetFrameRate command-line option 5-12, 6-
--textureSize command-line option 60-6
--threads command-line option 60-5
--timeManagement command-line option 4-19, 5-
--unbatchedRendering command-line option 5-5
--unplug command-line option 5-7
--useAbsoluteTimeStamps command-line option 5-7, 5-12
--useAdvisories command-line option 5-8, 5-12
--useAsyncIO command-line option 5-9, 5-13, 5-
--useFileCommChannel command-line option 5- 7
--useGeographicDdm command-line option 5-8
--useIpv6 command-line option 5-9, 5-13
--userDataDir command-line option 5-7, 5-12
--useReverseZBuffer command-line option 5-7
--version command-line option 5-7, 5-12, 5-14,
--visualTerrain command-line option, Simulation Object Editor 64-5
--vtFile command-line option 60-5
--waitQueue command-line option 5-12
-debug command-line option 5-14, B-11
-G command-line option 5-14 Simulation Object Editor 64-5
-h command-line option, Simulation Object Editor 64-5
-v command-line option, Simulation Object Editor 64-5
B-- command-line option 5-14, B-11 F-- command-line option 5-14, B-11
2525B icon 83-2 2D
using image for 65-22 label, shadow text 18-16
observer, attachment behavior 50-15 observer coordinate system 49-7 projection, switching to 3D 48-2 window 4-13
2D check box 65-25 2D icon, color 18-15
2D Icon model set 48-11 3D
observer coordinate systems 49-7
3D (continued)
projection, switching to 2D 48-2 window 4-13
3D Cartesian coordinate system 33-18 3D Colorized Models model set 48-11
color, changing 19-26 3D Models model set 48-11 3DS 80-5
3DS ASCII Export format 27-3 9-Line briefing 28-7
-A command-line option 5-8, 5-13, 5-20, 60-4
-a command-line option 5-7, 5-8, 5-9, 5-15 Abandon Plan command 36-42 abandoning plan 25-1, 36-42
Absolute mode 50-7 acceleration
specifying measurement unit 78-11
acceleration-to-rpm-factor parameter 9-18
action category 26-36, 32-8, 32-18
actionCategories.tsk 26-36, 32-18 Activate Jammer task 31-4 activating
scenario event from plan 8-11 activation, indirect fire 39-19 Activation set data request 40-3 active
tactical graphic 39-19, 40-3 Active Sonar Mode dialog box 34-5
Active Sonar Mode set data request 34-5 active-radar-sensor system 23-17
activity
Activity dialog box 34-6 Activity set data request 67-16 actuator 15-8, 15-9
missile-collision 72-12, 72-13
Add Conditional Expression dialog box 35-6 Add Group of Entities, dialog box 21-8
Add Model Definition dialog box 81-12 Add Props page 55-22, 63-9, 63-13, 63-20
Add Terrain Patch dialog box 55-6, 63-3, 63-21 Add Visualizer Definition Attribute window 81-30 adding
attribute, visual definition 81-30 category 64-19, 64-20
component to object in OPD Editor 70-8 default overlays 65-8
DI-Guy character 68-3 entity bitmap image 83-9 entity to unit 24-7 environment condition 11-7
global commands to plan 36-30 group of entities 21-8
media to scenario event 8-5 model, visual 65-24
object, to Favorites list 16-27 object geometry 65-14
ocean layer 55-15, 55-16 parameter
schema 81-7 pedestrians, to crowd 29-3 plug-in 4-34
adding (continued) power type 72-23
from feature layer 55-22 sensor component 71-11
system to simulation object 65-30 terrain patch to terrain 55-5 terrain server 56-4
text, to title bar 78-10 text object 39-5
additional-algorithm-config parameter 72-29 additionalDestinationAddresses parameter B-7 additional-opds parameter 12-6 additionalSystemScriptsDirectory parameter B-2 addMulticastAddr parameter B-7
adjusting, sound volume 47-3 advanced navigation 58-2
advisory message, enabling and disabling B-7 agent, contamination 23-7
aggregate, See also unit Aggregate As
specifying a unit as option 66-3 aggregate warfare model 23-2, 67-3
aggregate-comms-jammer, system 23-16
aggregated unit 22-2 attack by fire 31-5
aggregate-formation-controller parameter 73-2
aggregate-level modeling 21-1 aggregate-level unit, parameter 67-4 AggregateLevel.sms 15-11, 23-2, 67-3
aggregate-object-param parameter 69-25 aggregate-param parameter C-8 aggregate-radar-jammer system 23-17
aggregateSpatialModelTickAsFastAsPossible-
aggregateSpatialModelTickPeriod parameter B-2
aggregateSpatialModelTickPeriodUsesRealTime
parameter B-2 aggregateSpatialModelTickVariance parameter B-2 aggregation
aiming, sensor 34-38 Aiming dialog box 34-7 Aiming set data request 34-7 air, temperature 11-5
air temperature, ambient 11-10 air traffic, generating 27-12 aircraft
attacking with gun 28-3 landing at airport 27-12
See also Fixed-Wing entity and Rotary-Wing entity
airport, landing aircraft at 27-12 airspace 39-4
Air-to-Ground Attack dialog box 31-4 Air-to-Ground Attack task 31-4
alias, attribute transformation 62-4 Allow Crossing dialog box 40-4 Allow Crossing set data request 40-4
allowed-state-repositories-types parameter 72-32
all-tasks-exclusive parameter 26-35
alpha bits 5-3 Altitude
set data request 34-8 altitude 18-10, 33-18
observer, filtering simulation objects by 6-9 ordering entity to 27-15
altitude (continued)
fixed-wing entity 26-25 in dialog box 16-15 manually 16-15
specifying measurement unit 78-11 switching from 2D to 3D 48-2 testing entity for 35-10
vertex
displaying 37-10 altitude point
Altitude set data request 26-25
Always Join Session with Open Database 4-17 Always Join Session with Session Database 4-17 ambient
ambient air temperature 11-5, 11-10
ammo select file 72-4, 72-33 ammo select table 72-8
pacing and tracking 34-9 specifying amount 34-34
unit 67-5, 67-8 Ammunition dialog box 34-8
Ammunition Pacing/Tracking dialog box 34-9 Ammunition Pacing/Tracking set data request 34-
angle, damage 72-22, 72-26 Angle of Attack 83-12
angle-of-incidence parameter 72-22, 72-26
angleSegmentMax parameter 84-5 animated movement
movement file, configuring 65-51 Animated Movement dialog box 27-3, 65-52 Animated Movement task 27-3
observer view transition 49-32 testing DI-Guy 35-11
Answer Questions button 33-23 anti-air
anti-personnel 23-13 anti-ship
Anti-ship (Fixed Depth) task 28-14 anti-submarine, missile 28-12
anti-tank
anti-tank ditch, digging 31-13 Any, as condition parameter 36-22
Any Subordinate of Selected Aggregate check box 36-23
appData directory 5-9 appearance
specifying for DI-Guy model 65-16 testing DI-Guy 35-11
Appearance dialog box 34-10 Appearance set data request 34-10 appending, saved views to view list 49-33 appIdRange parameter B-7
application
data, specifying location of 5-3, 64-4
number 5-7, 5-8, 5-9, 7-41, 12-9
application (continued)
number 5-7, 5-8, 5-9, 7-41, 12-9
remote, notifying of VR-Forces run and pause 7-41
Application Settings dialog box 7-22, 24-11
File Caching Settings page 6-11, 61-2, 61-6
Key Mapping Editor page 80-4, 80-9 Mouse Mappings page 49-14 Performance Options page 6-15, 6-17 Script Options page 32-37
Session Options page 4-7, 7-10, 7-11, 7-12, 7-
Spot Report Options page 9-3, 9-5, 9-6, 9-8, 9-
applying, platform update 64-19
appNumber parameter B-2 arc, segment 84-5
creating for multiple entity creation 21-8 disaggregation 24-12, 37-2
extruded 35-12, 39-4 feature, list of 53-14 fill style 39-17
high fidelity damage 72-29 NBC 23-7
suppressive fire at 26-32, 28-17
Arm Mine at Depth task 28-3 Armed dialog box 34-11 Armed set data request 34-11 arming
armor-piercing power domain 72-18 arrow
freehand line 39-2 sensor contact line 42-15
Arrowhead Style dialog box 40-4 Arrowhead Style set data request 40-4
tasks for moving 30-11 artillery
ASCII Export file 65-47, 65-50
Ask to Join Session 4-17 assembly 67-5, 67-10
adding to entity 67-13 creating 67-11
removing 67-13 roll up rule 67-14 rolling up 67-15
assertOnBlockingTerrainCalls parameter 52-8, B-2
assigning
plan to multiple simulation objects 36-39 session ID 4-8
asynchronous I/O 5-20, B-8 using for performance 6-12
observer, articulated part 50-4
Attach Components to Remote Entities On parameter 7-5
attach mode 1-14, 49-3, 49-8, 50-7
Mimic Location Track 50-10 Mimic Track 50-10
movement, attached context 49-8 prop, affect of 50-6
Tether Location Track 50-13 Tether Track 50-13
Attach Object to Mouse check box 16-18 attached, context 49-8
Attached Near Clip Altitude, attribute 77-10 attaching observer
to simulation object or prop 50-2
attachment
preservation of view changes 50-3 Attachment Panel 50-2
filtering attachment list 50-5 attack
Attack Aircraft with Guns task 28-3 Attack By Fire dialog box 31-5 Attack By Fire task 31-5
attack parameter, edting 67-22
Attack with Anti-Air Missile dialog box 31-5 Attack with Anti-Air Missile task 31-5 attack with anti-ship missile 31-5
Attack with Anti-Ship Missile dialog box 31-5 Attack with Anti-Ship Missile task 31-5
Attack with Land-Attack Missile dialog box 31-6 Attack with Land-Attack Missile task 31-6 Attack with Torpedo dialog box 31-6
Attack with Torpedo task 31-6 attribute
Attached Near Clip Altitude 77-10 BOYSHP 57-24
building model definition 57-24 cockpit updater 83-10
Dynamic Near Clip Attached Policy 77-10 Dynamic Water Visibility Enabled 77-16 Dynamic Water Visibility Maximum 77-16 earth file, differential processing 57-21 feature 62-4
Fixed Near Clip When Attached 77-10 image 55-8
attribute (continued) MAK_SOURCE_FILE 62-4
modeldefinitionschema 83-6 Near Far Clip Policy 77-10 OBJNAM 57-26
Reduce Z Fighting Ratio 77-10 sensor 77-7
setting simulation object 34-10 SIGGRP 57-31
window 77-6 attrition
Audio Settings dialog box 47-2, 47-3, 47-5, 47-6,
Audio Settings page 47-2, 47-3
Auto Launch dialog box 34-13 automatic
aggregation and disaggregation 24-12 attachment 39-11
reorganization 34-33 running of scenarios 7-36
Automatic Air Defense task 31-6 Automatically Join Session 4-16 Automatically Open Session Database without
auto-reorganize parameter 12-5
avoidance, collision 3-16, 34-12 avoiding
collisions, obstacles, and features 19-16 objects 73-5
-B command-line option 5-9, 5-14, 7-39
balancing load 7-19 configuring feature data 55-11 console B-3
enabling time management 4-19, 5-19
feature representation 52-5 heartbeat B-5
late joining 3-7 mapping objects to 12-9 missing 3-8
multiple 3-2, 3-7, 12-9 reloading OPD B-3 remapping 3-8
in batch mode 7-39 sending messages 3-3
synchronizing 4-17 background
intervisibility information 46-11
background process 31-31, 32-5, 33-30 balancing, object load 7-19
ballistic gun, controller descriptor 72-8 ballistic missile 10-8
movement, configuring 65-48 movement file, configuring 65-51 scripted movement 65-47
Ballistic Missiles dialog box 65-48, 65-52 barbed wire, constructing 31-14 barricade, constructing 31-14
command-line option 5-9 configuring B-2
batch mode (continued)
starting from command line 7-39 batchScenarioFileName parameter B-2 beacon 57-31
wake 11-19 bead
emitter 9-17, 34-18 standard and tracking 34-18
bearing, intervisibility line 46-11 behavior
Behavior Set 32-9 assigning to force 26-21 creating 26-20
script availability 32-19, 32-21
best practice, model design 83-26 binary key mapping 80-4
binding, system definition file variable 69-21 Biological Attack dialog box 31-7
biological contamination 23-7, 23-8, 31-7 bit
depth and stencil 6-14 bitmap 52-4
adding to scenario event 8-5 displaying 55-7
blend image attribute 55-8 block
damage-by-munition-power 72-21
damage-model 72-21, 72-25, 72-37
high-fidelity-terrain-damage-table 72-29
standard-terrain-damage-table 72-28
Bomb Location dialog box 31-8 Bomb Location task 31-8
bomb-bay weapon system 72-17 booby trap
Boundary Generation Tool 57-14 running 57-16
boundary.txt 57-15 bounding box
simulation objects 18-30, 18-31
Bounding Volume check box 65-25 box
Breach Obstacles dialog box 31-9 Breach Obstacles task 31-9 breaching
brightness 45-4 broadcasting
stealth position and orientation 48-12 buffer, size 5-9, 5-13
conditional statement 36-11 creating entity in 19-4
bump map 1-15, 61-7 buoy
model definition 57-23, 57-24 using texture atlas 57-27
wake 11-19 buoyancy
enabling or disabling 44-7 LOD distance 44-7
burst
spawn pattern 20-12 button
common for model definitions 78-9 Joystick 75-6
-C command-line option 5-3, 5-14
-c command-line option 5-9, 60-4 C++
cache
clearing model instancing 6-11
cache (continued) model instance 6-11
caching
earth file, offline 61-5 file 61-2
terrain data 1-18 terrain server data 61-3
calculating, support point 65-12 calculating damage 72-17 camera
position and orientation 77-19 shaking 49-27
Camera Orientation Offset 77-7 Camera Position Offset 77-7, 77-19
can-be-radar-jammed parameter 23-17
canceling, reactive task 26-18
cancelling, generation of navigation data 58-8
can-pivot parameter 27-28 Capabilities dialog box 34-11 Capabilities set data request 34-11 capability, setting 34-11
car bomb, detonating 34-15 cargo
unloading 27-27 cargo door
carrier, placing entity on 19-4
Cartesian, coordinate system 33-18, 33-20
catastrophic-kill parameter 72-26 Categories, clearing list 65-9 Categories list 65-9
category
Props Palette, adding 83-14 removing 64-19, 64-20
category (continued) undoing changes 64-21
weapon and ammunition, adding 67-26 CDB database 57-17
CEO. See combat engineering object certainty level for spot reports 9-8 cgfDispatcherReceivePort parameter B-2 chaff 28-13
Change Hostility dialog box 9-12 Change MOPP Level dialog box 31-10 Change MOPP Level task 31-10, 34-27 Change Posture dialog box 31-11 Change Posture task 31-11, 34-30 changing
2D icon image 65-22 3D model 65-20
channel attributes 77-7 color
control object 39-12 entity
extended label index 18-19 field of view 77-14
force hostility 9-10 frame rate mode 12-6 gain 49-30
image display order 55-10 intervisibility object 46-8
model definition, prop 63-23 model set 48-11
name, tactical graphic 19-6 object category 65-3
changing (continued) posture 31-11, 34-30 prop
model definition 55-26 position or orientation 55-26 type 55-26
Simulation Time Scale Toolbar range 7-25 site ID 12-9
spot report icon 65-23 subordinate order 66-6
terrain database for scenario 12-8 unit of measurement 78-11
viewport 77-15 width of line 39-17
window attributes 77-6 channel
projection resize policy 77-11 property 77-7
ChannelKeyword parameter 83-12 character
specifying for DI-Guy model 65-16 character_animations_table.mtl 68-3 check box
Bounding Volume 65-25 Color by Force Type 18-15 Daylight 65-25
Marker Labels 65-25, 65-31 checking
checking waypoint accessibility 21-6 checkpoint 7-27, 7-30
checkpoint (continued) periodic, scheduling 7-32 rolling back to 7-25 saving 7-30
saving from snapshot 7-31 scenario 7-30
Checkpoint Settings page 7-26, 7-32, 7-33, 7-34 Chemical Attack dialog box 31-11
chemical contamination 23-7, 23-8, 31-11 child, element definition 81-21
choosing, window layout 78-5 chop, wave 11-16
for firing at target 9-15 icon, color 9-13
civilian, creating 21-2 Civilian Idle task 29-2
civilian visit point 21-9, 21-10 clamp image attribute 55-8
clamp to border image attribute 55-8 clamp to edge image attribute 55-8 clamping, entities 19-20
class
DtSimObjectStateRepository 69-9
VR-Forces 69-3 Classified CID level 9-13 clearing
default window layout 78-6 file cache 61-6
model instancing cache 6-11 object console 18-35
Used By Countries list 65-9 view list 49-32
adjusting when creating simulation objects 19-4 clock mode 3-11, 12-6
Close Cargo Door task 30-11 Close Door task 29-2
Close Window task 29-2 closing
Create Object dialog box 16-13 door 29-2
window 29-2 cloud
skybox cube map 43-14 smoke 28-13
cockpit display 51-6, 82-2, 83-10
element definition 81-21 enabling or disabling 51-3 installing 83-11
model definition, creating 83-11 updater 83-10
Cockpit Display Settings page 51-5 code
coefficients determinant 72-23 collapsing
collision avoidance 3-16, 19-16
configuring 73-4 specifying for entity 34-12
Collision Avoidance Types dialog box 34-12 Collision Avoidance Types set data request 34-12 color
2D label background 18-16 altitude point
emitter volume, pulse rate 84-2 entity label 18-9
intervisibility, configuring 46-9
partially identified simulation objects 9-13 pattern 57-24
radio communication line 42-23 represents emitter volume frequency 84-2 sensor contact line 42-15
squawk indicator 42-23 tactical graphic vertex 39-17
tactical graphics, changing 39-16 terrain, configuring 53-5
unit bounding volume 25-11 Color by Force Type check box 18-15 Color dialog box 40-4
Color set data request 40-4 coloring
colorized model, changing 65-20 COLOUR attribute 57-24
combat engineering object 23-9 as feature 62-10
completion percentage, setting 34-29 configuring 67-25
creating new model 67-3 partial completion 23-12 rate of creation 23-12
combat engineering object (continued) status 23-12
combat identification level 9-13 combined mode, vrfLauncher 5-15 combining, key mapping 80-8 Come to Stop task 27-4
command
global, adding to plan 36-30 Issue Plan 36-34
Restart Plan 36-41 command line
loading scenario from 7-18 loading terrain 5-7
command-line, Simulation Object Editor 64-4 command-line option 5-1
--additionalSystemScriptsDirectory 5-9
--countryCodesMappingFile 5-10
--defaultObjectTimeout 5-8, 5-10
--defaultSimulationModelSet 5-3
command-line option (continued)
--doNotCheckPluginVersions 5-3
--doNotLoadVrfPlugins 5-3, 5-10
--fileTransporterReceivePort 5-4, 5-8
command-line option (continued)
--hostAddressString 5-8, 5-9, 5-10
--ignoreZoomForSpeedtreeLod 5-7
--loadSimulationObjectGroup 5-5
--localSettingsDesignator 5-8, 5-13
--mergeHierarchyEntityDef 5-5, 81-34
--mergeHierarchyTacticalGraphicsDef 5-5, 81-
--mergeHierarchyUnitDef 5-5, 81-34
--mergeLeafEntityDef 5-5, 81-34
--mergeLeafTacticalGraphicsDef 5-6, 81-34
--mergeTacticalGraphicsTypeMap 5-6
--multicastAddresses 5-9, 5-13
--noAppDataEntityDefs 5-6, 81-34
--noAppDataModelDefs 5-6, 81-19
--noAppDataTacticalGraphicsDefs 5-6, 81-34
--noAppDataTacticalGraphicsTypeMap 5-6
command-line option (continued)
--noAppDataUnitDefs 5-6, 81-34
--nonVrfObjectsUUIDScheme 5-6, 5-11
--setMainThreadToHighPriority 5-11
--simArgs 5-14 Simulation Object Editor
--doNotCheckPluginVersions 64-4
command-line option (continued) Simulation Object Editor
--suppressHatIntersectOnAttach 5-7, 50-6
--timeManagement 4-19, 5-13, 5-19
--useAbsoluteTimeStamps 5-7, 5-12
--version 5-7, 5-12, 5-14, 60-5
comma-separated values file 10-8 comment
comm-model-name parameter 74-4
commModelParams.mtl file 13-3, 74-4 communication
communication model 13-2, 74-4
comparison operator 35-13 compass
adding to object in OPD Editor 70-8 architecture 15-8
attaching to remote entities 7-5 attaching to remote entity 76-2 communication among 15-8
creating connection in OPD Editor 70-10 deleting in OPD Editor 70-7
descriptor, elements of 69-13 emitter 34-18
performance 6-13 component attachment table 76-2
Component Attachment Table parameter 7-6 Component Manager C-5
Component-Attachment parameter 12-5
Component-Attachment-Table parameter 12-5
componentAttachmentTable.mtl 76-2
component-descriptor-type 69-13 component-manager parameter C-5, C-7 component-type 69-13
compressing, model and image files 83-27 compression, texture 61-6
computed route, creating 39-7 Concealed dialog box 34-13 Concealed set data request 34-13
concurrent task 25-1, 26-5, 32-18 condition
considerations for using 35-10 Detect Entity 35-10
Engineering Object Breached 35-10 Entity Altitude 35-10
Entity Di-Guy Animation Check 35-11 Entity Di-Guy Appearance Check 35-11 Entity Embarked 35-11
Entity Has Target 35-11 Entity In Area 35-12, 39-4 Entity Left of Line 35-12 Entity Under Fire 35-12 If, creating 36-5
Lifeform Surrendered 35-12 Missile Approach Warning 35-12 name 36-23
name condition, pattern 36-22 pattern 36-24
editing CSV file 36-24 Random 35-13
Receive Text Message 35-13 Resource 35-13
Tactical Graphic Active 35-14, 39-19, 40-3
conditional expression dialog box 36-11 conditional statement 35-4
filtering simulation object list 26-10 trigger 35-7
condition-entity-types.csvfile 36-24
configName parameter 83-19, 83-21 configuration
environment 5-4 file
condition-entity-types.csv 36-24
plug-in, deleting 4-36 simulation model set 7-9
configuration file
character_animations_table.mtl 68-3
commModelParams.mtl 13-3, 74-4
for object parameter database 64-5 navigation area 58-10
sysdef 69-17 vrfSim.mtl B-2 vrfSimSettings.xml 6-15
configuring
aggregate-level entity 67-3 back-end
ballistic missile movement 65-48 batch file B-2
combat engineering objects 67-25 communication model 13-2
condition pattern enumerations 36-24 context-sensitive menu 79-5
Create Object dialog box 16-13 damage-by-power 72-18
depth of field 49-25 destination address B-7 detection tables 9-13 dialog box
character and appearance 65-16, 68-3 direct fire weapon 72-4
external communication model 13-3 feature avoidance 73-5
configuring (continued) feature data 62-2 FED file name B-6
federation execution B-6 name B-6
fixed weapon system 72-16 FOM Mapper B-6 formations 73-2
frequency of data sends B-3 GDB soil type 53-2
GUI elements 79-2 heartbeat threshold B-7 HLA B-6
ingress and egress points 65-36 instrument panel 51-7
keyboard entity control 75-2 map datum B-6
movement file 65-51 multicast address B-7 multichannel display 77-17 mutually exclusive tasks 26-35 object avoidance 73-5
obstruction avoidance 73-4 ocean planar reflection 43-10 orientation clamping 19-22 path, to OPD file B-3
power of detonation 72-19 projection resize policy 77-11 props 52-4
radio message model 13-2 radios 74-4
range rings 18-27 receive port B-2
rotary-wing lateral movement 26-32 scenario file to use B-4
sensor contact line 42-15 sensor effects 45-4
configuring (continued) sensors 71-2
signature propagator 71-9 simulation management message B-5 site ID B-5
slot exclusion 65-40 start mode B-5 stereo
polarized 77-22 system for MÄK RTI 2-9 terrain color settings 53-5 terrain database
time management 4-18 time stamp order B-7 toolbar 79-6
unit, ammunition, weapons, equipment 67-5 visual quality slider 6-16
VR-Forces for external communications effects server 13-2
confirmation prompt
plan, enabling or disabling 26-6 task, enabling or disabling 26-6
connecting, to network automatically 5-3 connection
configuring in system definition file 69-18 information 4-31
simulation object group 65-46 Connection Information dialog box 4-31 console
configuring for back-end B-3 messages
setting notification level 34-28 constrained, time 4-17
Construct Abatis dialog box 31-12 Construct Abatis task 31-12
Construct Anti-Tank Ditch dialog box 31-13 Construct Anti-Tank Ditch task 31-13 Construct Barbed Wire dialog box 31-14 Construct Barbed Wire task 31-14
Construct Barricade dialog box 31-14 Construct Barricade task 31-14 Construct Berm dialog box 31-15 Construct Berm task 31-15
Construct Booby Trap dialog box 31-15 Construct Booby Trap task 31-15 Construct Bridge dialog box 31-16 Construct Bridge task 31-16
Construct Dry Gap dialog box 31-17 Construct Dry Gap task 31-17
Construct Fortified Area dialog box 31-18 Construct Fortified Area task 31-18 Construct Fortified Line dialog box 31-19 Construct Fortified Line task 31-19 Construct Minefield dialog box 31-20 Construct Minefield task 31-20 Construct Strong Point dialog box 31-21 Construct Strong Point task 31-21 constructing
terrain 55-5 contamination
nuclear, biological, chemical 23-7, 23-8
type, setting 34-13 Contamination dialog box 34-13
Contamination set data request 34-13 context-sensitive menu 78-9
configuring 79-2, 79-5 contour line
Contour Lines page 53-9, 53-10
control, remote 1-16 control object 37-2, C-7
list of for scenario 12-10 name 37-2
dynamic-terrain-munition-damage 72-28
indirect fire weapon 72-14 joystick 75-2
making decisions and performing tasks 15-9 missile 72-12, 72-13
target selection 72-6, 72-11, 72-13 controlling
remote 49-34 conventions, manual lvii convoy 27-4, 27-5
Convoy To task 26-11, 27-5 coordinate
Cartesian 33-18, 33-20 changing unit of 78-11 geocentric 52-6
supported 52-6 copying
copying (continued) performance and 16-21
corridor 39-4 count
counter measure 28-13 ammo select table 9-19 launching 9-19
Counter Measures Auto Launch, set data request 9-19
Counter Measures Auto Launch set data request 34-13
countryCodesMappingFile parameter B-2, B-4 CPU time, giving up 6-17
Create Anti-Tank Ditch dialog box 31-13 Create Barbed Wire dialog box 31-14 Create Barricade dialog box 31-14
Create Berm dialog box 31-15 Create Booby Trap dialog box 31-15 Create Bridge dialog box 31-16 Create Connection dialog box 70-10 Create Dry Gap dialog box 31-17
Create Fortified Area dialog box 31-18 Create Fortified Line dialog box 31-19 Create global command 36-33
Create Indirect Fire dialog box 10-3 Create Intelligence Object dialog box 8-8 Create menu 16-3
assigning or removing simulation object 65-7 selecting object 16-8
Create Minefield (ADAM-RAAM) dialog box 31- 24
Create Minefield (Volcano) dialog box 31-20 Create Multiple Entities, dialog box 21-7 Create New Component dialog box 70-8 Create New Entity dialog box 65-32
Create New Entity Type Model Mapping dialog box 82-4
Attach Mouse to Object 16-18 configuring 16-13
Create Object dialog box 16-13 Create Pedestrians dialog box 21-3 Create Pedestrians task 29-3 Create Resource dialog box 70-11 Create Route dialog box 16-16
Create Scenario Event dialog box 8-3
Create Spawn Pattern dialog box 20-10, 20-14 Create Strong Point dialog box 31-21 Create_Global_Dynamic_Terrain parameter 12-6
Create_Global_Environment parameter 12-6 Created Object variable 35-15
create-script-id parameter 32-21
aggregate-level entity 67-3 area for multiple entities 21-8 assembly 67-11
combat engineering object 23-11 component connection 70-10
demonstration recordings 36-35
adjusting clipping plane 19-4 fixed-wing 26-23
indirect fire event 10-3 inset view 51-2
MEDF and MEIF files 83-27 minefield 31-20
creating (continued)
object 16-3, 16-4, 16-5, 16-8, 16-11
selection group from menu 17-9 simulation model set 64-17, 64-18
simulation object 16-3, 16-4, 16-8, 16-11, 19-3
simulation objects, multiple 21-2 sink points 20-4
system definition file 69-17 tactical graphics 16-9, 39-2
crouching 34-31 crowd
crowd (continued)
gathering at location 29-4 protesting 29-7
Crowd Along Line dialog box 29-3 Crowd Along Line task 29-3 Crowd Around Location task 29-4 Crowd Around Object task 29-4
Crowd in Front of Entity dialog box 29-5 Crowd in Front of Entity task 29-5
cruise missile, firing 28-10 CSV, file 27-3
configuring for ballistic missile or animated movement 65-51
cube map, recalculating 43-14 culling, face front 44-8 cultural feature 16-26, 65-9
creating 16-3, 16-4, 16-5, 16-8, 16-11
cultural-feature-param parameter 69-12, C-8 cultural-feature-state-repository 69-12 Current Speed dialog box 34-14
Current Speed set data request 34-14 cursor 16-9, 16-10
curvature of the earth display, mode 42-22
custom, plan 20-2, 20-9, 20-12
customizing, object parameter database 69-27 cut-in site 57-14
-d command-line option, vrfSim 5-10 daemon
running vrfSim as B-2 starting back-end as 5-10
damage
damage (continued) model 65-28, 65-29
damage file 72-4, 72-17, 72-21, 72-35, 72-37
damage system 72-4, 72-10, 72-17, 72-34, 72-37
damage-by-ammo-type 72-10, 72-17, 72-25
damage-by-munition-power block 72-21
damage-by-power 72-10, 72-17, 72-24
damage-model block 72-21, 72-25, 72-37
dashed line 39-17 data
configuring frequency of sends B-3 directory 2-4
specifying location of 5-3, 64-4
synchronizing 4-23 data directory
data distribution management 6-8, 6-9
See also DDM database 52-6
dataset, virtual and tiled 60-4 date 11-2
date (continued)
setting in new scenario 7-7 simulation 7-11
Date and Time page 11-3, 11-4 datumShiftX parameter B-3 datumShiftY parameter B-3 datumShiftZ parameter B-3 daylight, controlling light 43-7 Daylight check box 65-25
daylightControlledLights parameter 43-7
daylight-illumination parameter 71-13
day-night-transition-time is parameter 71-13 DDM 6-8, 6-9
flipping 55-6, 83-21 Deactivate Jammer task 31-21 deactivating, jammer 31-21
debug mode, running from vrfLauncher 5-15 debugging
earth file 61-14 Navigation Lab B-3 shaders 61-8
decal effects 42-3, 82-2 enabling and disabling 42-4 models 42-4
decal image attribute 55-8 decay rate for spot reports 9-8 decision making 15-9
decreasing speed of navigation 49-28 default
settings, restoring 4-21 simulation model set 5-3
simulation model set configuration 7-11 spawn pattern 20-9
starting date and time 7-12 value, parameter 12-10
default (continued) view 49-32
default_guiConfiguration.gui 79-2
default_guiSimpleScenarioPlayer.gui 79-2 DefaultEllipsoidArc, model definition 84-2 defaultHeartbeatThreshold parameter B-7 defaultObjectTimeout parameter B-7 DefaultObserverView parameter 12-6 defaultParameterDatabasePath parameter 12-7, B-3 defaultSpawnTemplates.mtl 20-9
default-task-rules.tsk 26-35, 32-18 defaultTerrainDatabasePath parameter 12-7, B-3 defense parameter, editing 67-23
defensive
movement 31-28 definition
parameter 70-4 degrees of freedom 85-7 delay parameter 72-29
Delete Checkpoints dialog box 7-33
Delete Object global command 36-33, 36-34 Delete Self, command 20-9
Delete Self global command 36-34 deleting
from simulation model set 65-34 environment condition 11-8
messages from object console 18-35 model definition 81-13
object from selection group 17-10
deleting (continued) observer 48-9
object 39-11 parameter
parameters and components in OPD Editor 70- 7
plan statement 36-10 plug-in
Deliberate-Attack, posture 23-4
Deliberate-Defense, posture 23-4 demonstration
Deploy Refueling Boom task 30-12 Deploy Sonobuoy task 30-17
Deploy Sonobuoys Along Route task 30-17 deploying
sonobuoy 30-17 depth
depth of field 49-23 configuring 49-25
enabling and disabling 49-23 descent rate 27-10
spawn pattern 20-10 deselecting
destAddrString parameter B-7 destination address 5-8, 5-13, B-7 Destroy Bridge dialog box 31-22 Destroy Bridge task 31-22 Destroy Ditch dialog box 31-22 Destroy Ditch task 31-17, 31-22
Destroy Explosive dialog box 31-22 Destroy Explosive task 31-22
Destroy Fortification dialog box 31-23 Destroy Fortification task 31-23 Destroy Obstacle dialog box 31-23 Destroy Obstacle task 31-23
destroyed, setting simulation object to 34-14 Destroyed set data request 34-14 destroyedsymbol attribute 83-8
destroyFedExec parameter B-6 destroying
federation execution B-6 fortification 31-23
destroy-script-id parameter 32-21 detaching, observer from object 50-5 Detect Entity condition 35-10 Detected CID level 9-13
detection table 9-13 detection types, sensor 71-9 detection-types parameter 72-6 determinant
determinant (continued) power 72-19
detonating, IED and car bomb 34-15 detonation
configuring power of 72-19 effects 42-8, 82-2
event
mapping sound effects to 47-4 sound effects 47-2
result, sound mapping 47-8 sound mapping 47-8
Detonation Fuse Type dialog box 34-15 Detonation Fuse Type set data request 34-15 detonation interaction 72-13
Detonation Sound Editor page 47-9
detonation-munition parameter 72-29
detonation-on-destroy parameter 72-29
detonationParams.mtl 72-15, 72-18, 72-21, 72-
Device address 5-8, 5-13 deviceAddress parameter B-7 dialog box 27-12
Active Sonar Mode 34-5 Activity 34-6
Add Conditional Expression 35-6 Add Group of Entities 21-8
Add Terrain Patch 55-6, 63-3, 63-21
Ammunition Pacing/Tracking 34-9
Application Settings 7-22, 24-11
File Caching Settings page 6-11, 61-2, 61-6
Key Mapping Editor page 80-4, 80-9 Mouse Mappings page 49-14 Performance Options page 6-15, 6-17
Application Settings 7-22, 24-11 Script Options page 32-37
Session Options page 4-7, 7-10, 7-11, 7-12,
Spot Report Options page 9-3, 9-5, 9-6, 9-8,
Arrowhead Style 40-4 Attack By Fire 31-5
Attack with Anti-Air Missile 31-5 Attack with Anti-Ship Missile 31-5 Attack with Land-Attack Missile 31-6 Attack with Torpedo 31-6
Audio Settings 47-2, 47-3, 47-5, 47-6, 47-7,
Ballistic Missiles 65-48, 65-52
Change Hostility 9-12 Change MOPP Level 31-10 Change Posture 31-11
Collision Avoidance Types 34-12 Color 40-4
conditional statement 36-11, 36-23
Construct Anti-Tank Ditch 31-13 Construct Barbed Wire 31-14 Construct Barricade 31-14
Construct Berm 31-15 Construct Booby Trap 31-15 Construct Bridge 31-16 Construct Dry Gap 31-17 Construct Fortified Area 31-18 Construct Fortified Line 31-19 Construct Minefield 31-20 Construct Strong Point 31-21 Contamination 34-13
Create Anti-Tank Ditch 31-13 Create Barbed Wire 31-14 Create Barricade 31-14
Create Berm 31-15 Create Booby Trap 31-15
Create Connection 70-10 Create Dry Gap 31-17 Create Fortified Area 31-18 Create Fortified Line 31-19 Create Indirect Fire 10-3
Create Intelligence Object 8-8
Create Minefield (ADAM-RAAM) 31-24 Create Minefield (Volcano) 31-20
Create Multiple Entities 21-7 Create New Component 70-8 Create New Entity 65-32
Create New Entity Type Model Mapping 82-4 Create Object 16-3
Create Route 16-16 Create Scenario Event 8-3
Create Spawn Pattern 20-10, 20-14 Create Strong Point 31-21
Crowd Along Line 29-3 Crowd in Front of Entity 29-5 Current Speed 34-14
Destroy Obstacle 31-23 Detonation Fuse Type 34-15 DI-Guy Characteristics 34-16 DI-Guy Hand Item 34-16 Display Settings 4-21, A-2
Cockpit Display Settings page 51-5 Display Units Settings page 78-13
Entity Display Settings page 18-12, 18-13,
18-21, 18-22, 18-23, 18-35, 19-21,
19-22, 19-26, 26-6, 42-12, 42-19, 44-
Grid Lines Settings page 53-8 Indirect Fire Settings page 10-7
Interest Management Settings page 6-9 Intervisibility Settings page 46-6, 46-7, 46-9,
Lighting Render Settings page 43-4, 43-5 Loader Settings page 61-11
dialog box (continued) Display Settings 4-21, A-2
Observer Settings page 18-26, 18-30, 18-31,
19-25, 19-26, 42-4, 42-5, 42-14, 43-
7, 44-3, 48-4, 48-5, 48-6, 48-9, 49-5,
49-24, 49-27, 49-30, 51-10, 53-7
Ocean Settings page 11-20, 43-9, 43-10, 43-
Radio Communications Settings page 42-21, 42-22, 42-23
Range Rings Settings tab 18-27
Render Settings page 6-7, 6-8, 6-18, 43-13,
Sensor Settings page 45-4, 45-5
Shadow Settings page 43-20, 43-21 SpeedTree Settings page 83-23
Symbol Decoration Settings page 18-14, 18-
Tactical Graphics Display Settings page 37- 8, 37-9, 37-10, 39-17, 41-3
Terrain Profile Settings page 46-12 Track History Settings page 42-7
Unit Display Settings page 25-7, 25-10, 25-
Duplicate Model Definition 81-14 Edit Activities 67-16
Edit Behavior Sets 26-20, 26-21 Edit Spawn Pattern 20-15
Edit Trigger Condition 36-7 Embark On 19-9, 30-7
Environment Settings 11-3, 11-4 Environmental Object Information 18-3 Equipment Pacing/Tracking 34-20 Execute Close Air Support 28-7 Experimental Features 11-21, 49-20, 49-21 Fast Rope Insertion 27-6
Fire Cruise Missile 28-10 Fixed Wing Land 27-7 Fixed Wing Takeoff 27-8 Flee From Entities 29-6 Follow Entity 27-11
Food, Water, Motor-Gas, Aviation-Fuel, Diesel Fuel, Oil, Lubricant 34-20
dialog box (continued)
Food, Water, Motor-Gas, Aviation-Fuel, Diesel Fuel, Oil, Lubricant Pacing/Tracking 34- 21
Improve Booby Trap 31-24 Improve Breach 31-25
Initial Scenario Information 7-3, 7-11
Line Width 40-5 Load Batch File 7-39 Load Overlays 38-5
Manage Reactive Task 26-17 Manage Reactive Tasks 21-10 MOPP Level 34-27
Move Along Route 27-13 Move Into Formation 27-14 Move to Altitude 27-15 Move to Depth 27-15
Move to Location 27-16 Move to Waypoint 27-20
Munition Target Settings 10-3, 10-6, 10-8, 10-
Pattern Hold (Location) 27-24 Pattern Hold (Waypoint) 27-25 Pen Style 40-6
Preferred Targets 34-32 Protest Along Line 29-7 Protest Around Location 29-7 Radar Mode 34-33
Resources Pacing/Tracking 34-34
Resupply Mode 34-35 Rotary Wing Land 27-26 Rules of Engagement 34-36 Sail Heading 27-27
Scenario Snapshots 7-26, 7-31, 7-33, 7-34
Scenario Startup 4-6, 4-7 Sector of Responsibility 34-37
Sector Search Operation 28-20, 30-15 Send NBC Report 31-29
Send Obstacle Report 31-30 Set Scenario End Time 7-35 Set Sensor Signatures 8-9
Simulation Connections Configuration 4-32 Simulation Object Type Mappings 82-2 Sonar Depth 34-40
Strafe Ground Target 28-22 Superior 34-42
Surrendered 34-42 Synchronize Laser Code 34-43 Target 34-43
Terrain Settings
Add Props page 55-22, 63-9, 63-13 Earth Layers page 53-12
Edit Existing Props page 55-24, 55-25, 55-
Terrain Settings
Extract Props page 55-20, 63-21
Raster Maps page 55-7, 55-10, 63-5 SpeedTree Randomization page 83-25 Terrain Contents page 55-6, 55-12, 55-15,
55-16, 55-27, 56-3, 61-15, 63-3, 63-
Visible Surfaces page 53-3 Throw Grenade at Location 28-23 Throw Grenade at Target 28-24 Tracer Use 34-44
Turn to Heading 27-28 Unit State 34-44
Visual Model Editors 81-9 Wait Duration 30-11
Wait Until Expression 36-6 Weapons Pacing/Tracking 34-45
While Expression 36-6 Window Layout Manager 78-4
diffuse, color 43-4 digging
anti-tank, ditch 31-13 DI-Guy
adding new characters 68-3 animation
testing for 35-11 appearance, testing for 35-11 character data file 5-10
choosing animation 68-5, 82-10 configuring B-3
animations and appearances 5-10 character and appearance 65-16, 68-3 use of B-6
integration with VR-Forces 29-5 license 1-17
DI-Guy Characteristics dialog box 34-16
DI-Guy Characteristics set data request 34-16 DI-Guy Hand Item dialog box 34-16
DI-Guy Hand Item set data request 34-16
DI-Guy Settings page 6-20 diGuyAnimationsFile parameter B-3 dipping, sonar 30-18
direct fire weapon, configuring 72-4 direct fire weapon system
damage-by-ammo-type, example 72-36
damage-by-power, example 72-31 direction
wind 11-9 directory
back-end data 5-10 back-end user data 5-12 data 2-4
DirectX 61-10 DIS
command-line options 5-20 configuring B-7
encoding information in OpenFlight format 85-2
exercise ID 5-9, 5-13 heartbeat, threshold B-7 IPV6 5-13
specifying broadcast modes 5-20 starting in 5-3
DIS Enumeration Document 69-4 disable_if_checked 69-24
disable_if_multiple_selection 69-24
disabled-by-suppression parameter 26-34 disableParallelTick parameter B-3 disabling
advisory messages B-7 buoyancy 44-7
creation of a simulation object type 65-7 decal effects 42-4
editing of overlay 38-3 entity labels 18-13
disabling (continued) environment 43-18 frame rate statistics B-4 intervisibility 46-10
periodic checkpointing 7-32 radio communication lines 42-21 range rings 18-24, 18-26
Scenario Startup dialog box 4-7 sensor contact line 42-13 shadows 43-19
spot report for simulation object 34-41 squawk indicators 42-21
terrain paging information 56-7 texture compression 61-6
track histories for all simulation objects 42-5 trailing effects 42-4
wireframe mode 53-10 disaggregated state, unit 24-9 disaggregated unit 22-2 disaggregation
all entities on parent 19-12 in echelon view 19-11
Disembark All task 30-3 Disembark task 30-3
Disembarked set data request 19-11, 34-17 disembarked status, testing for 35-11 disembarking
instantly 19-11 Disperse Crowd task 29-5 dispersing, crowd 29-5 display
dragging 49-15 field of view 77-14
display (continued) time, format 11-4
Display Engine Configuration Editor Panel 48-6, 77-3, 77-4, 77-5, 77-6, 77-8
display mode, curvature of the earth 42-22 Display Models check box 65-25
Display Settings dialog box 4-21, A-2 Cockpit Display Settings page 51-5 Display Units Settings page 78-13
Entity Display Settings page 18-12, 18-13, 18-
21, 18-22, 18-23, 18-35, 19-21, 19-22,
19-26, 26-6, 42-12, 42-19, 44-6, 44-8,
High Dynamic Range Settings page 43-16 Indirect Fire Settings page 10-7
Interest Management Settings page 6-9 Intervisibility Settings page 46-6, 46-7, 46-9,
Lighting Render Settings page 43-4, 43-5 Loader Settings page 61-11
Observer Settings page 18-26, 18-30, 18-31,
19-25, 19-26, 42-4, 42-5, 42-14, 43-7,
44-3, 48-4, 48-5, 48-6, 48-9, 49-5, 49-
Ocean Settings page 11-20, 43-9, 43-10, 43-14,
Radio Communications Settings page 42-21, 42-22, 42-23
Range Rings Settings tab 18-27
Render Settings page 6-7, 6-8, 6-18, 43-13, 49-
Sensor Settings page 45-4, 45-5
Shadow Settings page 43-20, 43-21 SpeedTree Settings page 83-23
Symbol Decoration Settings page 18-14, 18-15 Tactical Graphics Display Settings page 37-8,
Terrain Profile Settings page 46-12 Track History Settings page 42-7
Unit Display Settings page 25-7, 25-10, 25-11,
Display Settings Toolbar 18-15 Display Terrain parameter 7-6
Display Units Settings page 18-23, 37-10, 78-13 displaying
height-above-terrain lines 18-23, 37-10 intervisibility
object 46-7 label
levels of aggregation in Echelon View 25-4 navigation areas 58-5
other MAK 3D GUI viewers 48-12 panel 78-3
scenario information 7-21 Scenario Startup dialog box 4-7 segment outlines 84-6
tactical graphics 37-8, 39-19, 40-3 terrain profile, creating line 39-6 toolbars 78-3
transient intervisibility 46-6
distance, specifying unit 78-11 Distance To Attached, policy 77-10 Distributed Interactive Simulation 1-22
See also DIS
ditch
installing cockpit display, installing 83-11 plug-in, removing 4-35
specifying for plug-in 4-35 dockable panel 78-2
docking, panel 78-2 documentation, location of 2-4 DOF bead 85-7
domain, power 72-18 doNotUseConsole parameter B-3 door
cargo
Douglas sea state 11-16, 11-18
drag and drop, plan statements 36-40 drag-and-drop, canceling 16-20 dragging
object to new location 16-19 objects 34-26
view 49-15 drainInput
configuring B-4 for DIS B-7 for HLA B-6
dr-allow-gui-overrides parameter 6-16
draw call, coloring 6-18 drawing, box 39-3 driver
driving, on and off roads 26-22
Drop Naval Depth Charge at Location task 28-4 Drop Naval Depth Charge task 28-4
Drop Naval Mines Along Route task 28-6 dropping, mine 28-5, 28-6
dropping bomb 28-18 dropping from exercise 3-7 dry gap, building 31-17 DTED
DtSimComponentManager class 69-9
DtSimObjectNetInterface class 69-9
DtSimObjectStateRepository class 69-9
Duplicate Model Definition dialog box 81-14 dust cloud 42-3
dynamic lighting 43-2, 43-6 dynamic linked library 4-31
Dynamic Near Clip Attached Policy, attribute 77- 10
dynamic ocean 1-14, 11-16 enabling and disabling 11-17 layer 55-13
wake and spray, disabling 44-6 wakes 83-14
global dynamic terrain processor 7-7 dynamic terrain area 59-3
Dynamic Water Visibility Enabled, attribute 77- 16
Dynamic Water Visibility Maximum, attribute 77-16
dynamic-terrain-munition-damage controller 72-
dynamic-terrain-type parameter 72-29
-e command-line option 60-4 earth file 1-18, 52-5, 57-3
areal features 57-12 buoys and beacons 57-23 caching, offline 61-5
differential processing of attributes and elements 57-21
earth file (continued) including files in 57-5 loading DTED 57-6
template, earth file 57-5 Earth Layers page 53-12 echelon ID 15-3, 15-4, 15-6
echelon level, ghosted icons by 25-7 Echelon View 17-2, 24-7, 24-8, 25-4
expanding and collapsing units 25-4 ghosted units 25-6
Edit Activities dialog box 67-16
Edit Behavior Sets dialog box 26-20, 26-21
Edit Existing Props page 55-21, 55-24, 55-25, 55-
Edit Spawn Pattern dialog box 20-15 Edit Trigger Condition dialog box 36-7 editing 11-15
defense parameters 67-23 electronic warfare parameters 67-23 element definition 81-25
embarkation ingress and egress points 73-6 entity model 65-3
indirect fire event 10-6 intervisibility object 46-8
editing (continued)
movement system properties 67-20 navigation area 58-4
object
location, heading, altitude 19-5 scene 39-13
object map file 12-9 object parameters 65-3
overlay and overlay object 38-3 parameter 65-12, 70-4
posture, transition time 67-21 scenario description 7-23
weather zone, environment 11-15 window attributes 77-6
effect
fire and detonation 42-8 lighting 1-15, 61-7
electromagnetic emissions 34-18, 42-18
sensing 23-18 electronic
electronic warfare parameter, editing 67-23 elem file 81-35
element
earth file, differential processing 57-21 informationitem 79-4
informationpagecollection 79-3
adding visual definition 81-26 common buttons 78-9
exporting hierarchy and leaves 81-36 exporting to elem file 81-35
filtering list in Simulation Object Type Mappings dialog box 82-7
spot report, regenerating 65-21 element_type 69-24
elevation
coloring terrain by 53-4 data 52-3
intervisibility point, configuring 46-9 Elevation Color page 53-4, 53-5, 53-6
ellipse
undoing and redoing rotation 39-16 ellipsoid, reference B-3, B-5
Embark On, command 19-9 Embark On dialog box 19-9, 30-7
Embark task 19-8, 30-4 embarkation
editing ingress and egress points 73-6 egress point 65-36
embedded entity alternative 19-12 immediate 19-8
occupancy-director-controller 73-6
Embarkation View 17-2, 19-7, 19-8, 19-11 embarking objects in 19-10
embarkation-slot-entry parameter 73-6
embarkation-slots parameter 73-6 Embarked dialog box 34-17 embarked object, information 18-4
Embarked set data request 19-9, 34-17 embarking
in Embarkation View 19-10 instantly 19-9
embedded entity 19-12, 28-20, 30-15 assigning tasks to 19-15 configuring 19-13
deploying 30-14 deploying with task 30-16 recovering 30-14
restoring parent 19-15 Simulation Object Editor 19-13 system 19-13
EM-Emission update message 84-3 emission sensor 23-18
Emitter dialog box 34-19 Emitter Power 84-3
Emitter set data request 31-4, 31-21, 34-18 emitter volume
enable_if_checked 69-24 enableDebugDrawer parameter B-3 Enable/Disable Spot Reports tab 9-3 enableLogFileTimestamps parameter B-3 enableNavigationLabDebugging parameter B-3 enabling
advisory messages B-7 buoyancy 44-7
creation of a simulation object type 65-7 decal effects 42-4
editing of overlay 38-3 entity labels 18-13
external communication model 13-3 frame rate statistics B-4 intervisibility 46-10
radio communication lines 42-21 range rings 18-24, 18-26
Scenario Startup dialog box 4-7 sensor contact line 42-13, 42-14
terrain paging information 56-7 texture compression 61-6
enabling (continued)
track histories for all simulation objects 42-5 trailing effects 42-4
wireframe mode 53-10 ending
engagement, information 18-7 Engagement Results dialog box 34-19 Engagement Results set data request 34-19 engagement rules 34-36
Engineering Object Breached condition 35-10 Engineering Object Information page 23-12 entitiy, ways to add to scenario 7-16
entity
See also simulation object adding to, unit 24-7
adding to Props Palette 16-26, 81-10 aggregate-level
aircraft, attacking with gun 28-3 altitude
attaching observer to 50-2, 50-7
avoiding obstacles, features, and collisions 19- 16
body frame coordinate system 49-7 bounding volume 18-30, 18-31
category, changing 65-3 centering observer on 49-26 clamping to ground 19-20
component, attaching to remote 76-2 components 69-13
console message 18-31 controlling by keyboard 19-20 controlling with joystick 19-18 copying 16-21
creating 16-3, 16-4, 16-5, 16-8, 16-9, 16-11,
entity (continued)
creating 16-3, 16-4, 16-5, 16-8, 16-9, 16-11,
in Simulation Object Editor 65-32 creating group of 21-5
creating in plan 36-33 deleting 19-5
from simulation model set 65-34 deleting in plan 36-33 disembarking 19-7, 34-17
element definition 81-21 embarkation
embedded 19-12 enumeration
extents, zooming on scenario load 49-22 filtering 6-8, 6-9
route following 26-27 following
generating navigation data 58-9 ghosted 25-6
ground, road driving 26-22 ground clamping 19-22
heading, setting 16-17 icon
adding new image 83-9 changing size 18-21
instrument panel, configuring 51-7 intervisibility 46-4
enabling and disabling 18-13 pinning to display 18-13
level body frame coordinate system 49-7
entity (continued)
mapping sound effects to 47-4 messages, viewing 18-33
moving 16-19 moving to
object or entity 27-20 name 18-9, 18-10
notification level, object console 18-32 object geometry 65-14
pasting, control object 16-22, 16-23
properties, specifying at creation 16-13 random creation of 16-25
range ring 18-26 resource
monitoring 18-29 routes for aircraft 39-10
saving console messages 18-35 scaling, 3D model 19-23 secondary 50-10, 50-13 setting
collision avoidance types 34-12 target 34-43
spawning, maximum simultaneous 20-11 specifying for multiple entity creation 21-8 storing list of 12-10
surface
configuring wake 83-14 symbol, changing color 64-23
entity (continued) systems 65-28
velocity, publishing B-4 VR-Forces 3-9
wake, enabling and disabling 44-6 zooming to extents 49-22
Entity Altitude condition 35-10
Entity Behavior Options page 24-6, 24-11
Entity Definition Editor page 83-2, 83-15, 84-7 Entity Destroyed condition 35-10
Entity Di-Guy Animation Check condition 35-11 Entity Di-Guy Appearance Check condition 35-
Entity Display Settings page 18-12, 18-13, 18-21,
18-22, 18-23, 18-35, 19-21, 19-22, 19-
26, 26-6, 42-12, 42-19, 44-6, 44-8, 48-
Entity Editor. See Simulation Object Editor Entity Embarked condition 35-11
entity enumeration, changing 65-4 entity file, importing 64-18
Entity Has Target condition 35-11
Entity Image Symbol, visual definition 83-2, 83-4, 83-9
Entity In Area, condition 35-12 Entity In Area condition 39-4 Entity Left of Line condition 35-12 Entity List, filtering 17-6
Entity Mapping Settings page 82-4, 82-5, 82-7
Entity Sound Editor page 47-5, 47-6, 47-7 entity state repository 72-7
Entity Under Fire condition 35-12 Entity View 17-2
entrance, embarkation 65-36 entry point, scripted task 33-7
entVrfDataTimeThreshold parameter B-3
for condition patterns 36-24 in condition 36-22
published and matching 69-6 environment
Environment Conditions dialog box 11-13 Environment Conditions Settings page 83-17 Environment Settings dialog box 11-3, 11-4 Environment Settings Toolbar 11-4 Environment Settings toolbar 11-3, 11-4 environment variable
MAK_GEOID_GRID 55-4 MAK_VRF_ENABLE_DEBUG_DRAWER
OpenSceneGraph, anaglyphic stereo 77-21 OSG_CURL_PROXY 56-5
VRFSIM_OSGEARTH_CACHE_PATH 61-
Environmental Object Information dialog box 18- 3
Environmentals List, filtering 17-6 Environmentals View 17-2
model 11-2 equipment
pacing and tracking 34-20 unit 67-5, 67-8
Equipment Pacing/Tracking dialog box 34-20 Equipment Pacing/Tracking set data request 34-
equipment parameter, editing 67-24 equivalent task 32-23
escaping
EW-Comms-Degradation-Percentage 23-16
exaggerated reality 48-10 exaggerating, 3D models 19-23 exclusion, slot 65-40
executable, installation locations 2-4 Execute Close Air Support dialog box 28-7 Execute Close Air Support task 28-7 execution name, HLA, specifying 5-17 exercise
exercise-start-time parameter 12-6
exit, embarkation 65-36 exiting
full screen window 78-9 plan 36-42
expanded label 18-9 pinning to display 18-13
expanding
Experimental Features dialog box 11-21, 49-20,
Explode Charge at Depth task 28-9 explosion 42-9
explosive device, arming 34-11 explosive device system 72-16 explosive power 72-15 explosive power domain 72-18 exporting
element definition to elem file 81-35
exporting (continued) element definitions 65-27
model definitions 65-27 object type mappings 65-27 overlays to shapefiles 38-6 scripted task 32-32
extended name 32-12 extent, zooming to 49-22
external communication model 15-7, 74-4
external communications effects server, config- uring VR-Forces for 1-17, 13-2
external reference 83-26 external script, editing 32-38 Extract Ocean page 55-15 Extract Props page 55-20, 63-21 extracting
from terrain patch 55-20 water texture 55-15
extras file 12-5 extruded
extruded geometry 52-5 eyepoint. See observer
-F command-line option 5-4, 5-14
-f command-line option 5-7, 5-12, 5-18, 60-4 face front culling 44-8
factory
window layout, restoring 78-7 factory settings, restoring 4-21 fan, intervisibility 46-4
far clipping plane 77-9 FASCAM task 31-24
Fast Rope Insertion dialog box 27-6
Fast Rope Insertion task 27-6 favorite 16-8
adding or removing from list 16-27 joystick configuration 75-14
observer view 49-32 Favorites, clearing list 65-9 favorites.mst 16-27
configuration file 62-6 configuring avoidance of 73-5 coordinate 53-16
data
buoys and beacons 57-23 configuring 62-2
configuring in front-end and back-end 55-11 displaying 53-13
extracting from GDB 62-7 layer 62-7
dynamic 62-10 extracting as prop 55-20 geometry 52-5
UvAtlasMapper 83-20 vector, list of 53-14
adding prop from 55-22 name, specifying 62-2
Feature Settings page 53-15 featureconfig.txt
specifying 5-19 federate
federateName parameter B-6 federateType parameter B-6 federation execution
Feet Above Ground Level 83-12 Feet Above Mean Sea Level 83-12 FeetAGL updater 83-12
field of view 49-18, 49-19, 77-14, 77-15, 84-3
changing 77-14 file
damage 72-17, 72-21, 72-35, 72-37
scenario 6-1, 12-2, 12-3, 12-7
simulation model set 64-5 system definition 72-3
vrfSim.log 4-38 vrfSim.mtl B-2 vrfSimSettings.xml 6-15
File Caching Settings page 6-11, 61-2, 61-6
Filename parameter 83-11 filename_shp_map.txt configuration file 55-11 fill style 39-17
Fill Style set data request 40-5 filtering
earth file layers 53-12 element definition list 82-7 function list 80-9
model definition list 81-15 object attachment list 50-5 object lists 17-6
scripted task list 32-31 simulation object list 26-10 simulation objects
by observer altitude 6-9 in scene 6-8
finite state machine 33-6 fire
effects 42-8 event
mapping sound effects to 47-4 sound effects 47-2
at point, line, or area 26-32, 28-17 target 28-9
Fire Cruise Missile dialog box 28-10 Fire Cruise Missile task 28-10
fire interaction 72-11, 72-13 Fire Sound Editor page 47-9 Fire-for-Effect task 28-11
firepower-kill parameter 72-26
fire-when-fired-upon 34-36 firing
Fixed Near Clip attribute 77-10
Fixed Near Clip When Attached, attribute 77-10 fixed weapon system, configuring 72-16
Fixed Wing Land dialog box 27-7 Fixed Wing Land task 26-29, 27-7 Fixed Wing Takeoff dialog box 27-8
Fixed Wing Takeoff task 26-28, 27-8
fixed-frame best-effort 3-11, 12-6
fixed-frame-run-to-complete 3-11, 4-18
fixed-frame-run-to-complete keyword 12-6 fixed-wing
holding pattern 27-24, 27-25 landing at airport 27-12 strafing target 28-21
fixed-wing entity altitude 27-8
attacking with gun 28-3 circling a point 27-23 counter measures 28-13
creating routes for 39-10 dropping bombs 28-18 follow entity behavior 27-11 heading 27-9, 27-10
routes for 39-10 setting
takeoff and landing 26-26 taking off 27-8
terrain following 26-26 writing plans for 35-19
fixed-wing-entity-param parameter 69-12, C-8
fixed-wing-entity-state-repository 69-12 flag, movement in wind 83-18
flat earth, coordinate system 49-7 Flee From Entities dialog box 29-6 Flee From Entities task 29-6 FLEXlm 2-5
flight plan, generating air traffic from 27-12 flipping, DDS textures 55-6, 83-21
Fly Heading and Altitude task 27-10
Fly Heading task 27-9 flying
denseness of 11-10 height and color 11-11
same side 9-7 folder
adding scripted task to 32-32 removing scripted task from 32-32 scripted task 32-31
follow entity, fixed-wing entity behavior 27-11 Follow Entity dialog box 27-11
Follow Entity task 27-11 in plan 35-18
Follow mode 49-8, 50-7, 50-8 Follow Route task 27-13 following
module 5-8, 5-12 FOM Mapper
configuring B-6 initialization data 5-7, 5-12 initialization string B-6 library name 5-7, 5-12 specifying at startup 5-18
fomMapperInitData parameter B-6
fomMapperLib parameter B-6 food 23-13
pacing and tracking 34-21 setting 34-20
Food, Water, Fuel, Oil, and Lubricant Pacing/Tracking set data request 34-21
Food, Water, Motor-Gas, Aviation-Fuel, Diesel Fuel, Oil, Lubricant dialog box 34-20
Food, Water, Motor-Gas, Aviation-Fuel, Diesel Fuel, Oil, Lubricant Pacing/Tracking dialog box 34-21
Food, Water, Motor-Gas, Aviation-Fuel, Diesel Fuel, Oil, Lubricant set data request 34- 20
affect of posture 23-5 sensor 23-8
Behavior Set, assigning to 26-21 color
editing 64-23 hostility
changing 64-23 changing in plan 9-12 matrix 9-10
setting at runtime 34-21 Force dialog box 34-21 Force set data request 34-21
forceHostilty.mtl 9-10 forceParameterDbReload parameter B-3 format
expanding and collapsing in Formation Editor 66-10
file 73-3 layout
in plan 35-18 snap to grid 66-14 supported 34-22
formation (continued) user-defined 73-4
Formation Editor 66-9, 66-10, 66-12, 66-13 Formation set data request 34-22
in plan 35-18 fortification
fortified area, constructing 31-18 fortified line, constructing 31-19 forward arrow 65-46, 66-7 frame, length of 12-6
Frame Mode parameter 7-7 frame rate 5-12, 6-4, 6-17, 6-19
setting 5-4 statistics
enabling and disabling B-4 log file B-3
Frame Rate Monitor panel 6-5 Frame Time parameter 7-7 frame-mode parameter 4-19, 12-6
time management 4-18 framentation power domain 72-18 frameRateStatisticsLogFile parameter B-3 frame-time parameter 12-6
sampling rate 39-2 frequency
radio communication line 42-23 sampling for terrain profile 54-3
feature representation 52-5 joining session at startup 4-16 multiple 3-2
fuel (continued) setting 34-20
Full Knowledge CID level 9-13 full screen 5-7
window 77-2, 78-9 function
-G command-line option 5-4, 5-16
-g command-line option 60-5 gain 45-2
Gameware Navigation Lab 58-11 gamewareMemorySize parameter B-3 gasoline 23-13
GDB, extracting feature data 62-7 GDB terrain 52-3
configuring soil type 53-2 shapefile 52-4, 55-11
Generate Air Traffic From Flight Plans task 27-12 generating
air traffic from flight plan 27-12 navigation data 58-5, 58-6
traffic 20-2 geocentric
converting to geodetic B-3, B-5 coordinate system 49-7, 52-6
geodetic, converting from geocentric B-3, B-5 geographic DDM 6-9
geoid grid file 55-4 geometric, objects 33-18
object, adding to entity 65-14
geometry (continued) sharing 6-11
Geometry Grid Dataset 60-3, 60-7
ghosted
icon, by echelon level 25-7 unit 25-6
license 1-20 global
weather 7-7 global command
adding to plan 36-30 Create 36-33
global dynamic terrain processor 7-7 global plan 11-2, 35-2
God ray 43-12 graphic
adding to scenario event 8-5 buffer, depth and stencil 6-14 depth 5-3
fire and detonation 42-9 mode, wireframe 53-10
object, showing and hiding 37-6, 37-8
graphical object 37-2 changing, line width 39-17 deleting 39-11
spot report 9-9 graphical user interface 3-2
gravity, aligning cultural feature 65-15 grenade, hand 28-23, 28-24
grid line
Grid Lines Settings page 53-8 grid spacing, changing 66-14 ground, attacking from air 31-4
Ground Clamping Cutoff Distance Scale 19-22 ground truth 9-2, 9-4
ground vehicle
configuring obstruction avoidance 73-4 road driving 26-22
ground-entity-state-repository 69-12 ground-vehicle-param parameter 69-12, C-8 ground-vehicle-param parameter 69-3
group
locking 79-7 settings
Simulation Object Editor, layout settings 64-5
GuiObserverViews parameter 12-6
GuiScenarioSettings parameter 12-6
Gui-Terrain-Database parameter 12-5
gumball 18-7 gun
aircraft, attacking aircraft with 28-3
-H command-line option 5-8, 5-9
-h command-line option 5-4, 5-10, 5-14, 60-5 Halt Movement task 31-24
Hasty-Defense, posture 23-4 HAT, See height-above-terrain line hazard, area 23-8
Hazards/Obstacles Palette 11-14, 16-4, 16-5, 23-9
header file, objTypeEnums.h C-9 heading 18-10, 49-3
heading (continued) indicator 16-17, 18-11
pasting 16-23 rotating icon to 18-22 setting 16-3, 34-23
specifying measurement unit 78-11 turning to 27-28
Heading dialog box 34-23 Heading set data request 34-23 headlight 43-2, 43-6
restoring simulation object 34-35 Health dialog box 34-23
heartbeat
back-end, configuring B-5 DIS B-7
relationship to thresholds 6-15 varying B-7
heartbeatVariance parameter B-7
heavy lift system 27-25 height
ocean 55-15, 55-16 height map
ocean
height-above-terrain line 18-23, 37-6, 49-28
displaying 37-10 helicopter
rotor wash, high quality 44-5 terrain avoidance 26-31
heuristic, path planning 3-14 hide_by_default 69-24 hiding
hiding (continued)
vertex labels 37-9 hierarchy
displaying levels of aggregation 25-4 element definition 81-21
hierarchy file, importing 81-33 high dynamic range 43-16
High Dynamic Range Settings page 43-11, 43-16 high fidelity damage area 72-29
high-explosive, resource 23-13
high-fidelity-damage-table 72-29
high-fidelity-terrain-damage-table block 72-29
hit file 72-4, 72-35 hit probability
1516
federation execution name, specifying 5-17 parameters B-6
specifying federation execution 5-17 starting in 5-4, 5-5
time management 4-17 holding pattern
host address 5-8, 5-9, B-6, B-7 hostAddressString parameter B-6, B-7 hostile-fire-only parameter 26-34 hostility
changing, plan in 9-12 matrix, force 9-10
hostility relationships file 6-1, 12-10 hostname, license server 2-6
HUD. See cockpit display
human
human-param parameter 69-12, C-8 humans, adding to crowd 29-3 human-state-repository 69-12
-i command-line option 4-8, 5-8, 5-9, 5-10 icon
bitmap, adding new 83-9 borders 18-20
configuring 2D 83-2 heading, rotating to 18-22 image 83-4
adding new 83-9 level of nesting 25-6 location of 2-4
size, changing 18-21 spot report
yellow 9-13 ID
script 32-8, 32-11, 32-21, 33-15
unique 15-3 identification
simulation object, UUID 15-3 Identification Friend from Foe 34-24 identifier, site and application 3-4
identifying, simulation objects 15-3 idling, human 29-2
If block, creating 36-5 If statement 35-4, 35-6
If/Else Expression dialog box 36-5 IFF 34-24
information 18-4 IFF dialog box 34-24
IFF set data request 34-24 illumination 71-12
setting 11-2 image
texture coordinate system 55-9 imagery, filtering 53-12
imagesymbolmap attribute 83-7, 83-9
impact-point range 72-19 importing
element definition 81-33, 81-34
navigation data 58-10 object type mappings 65-26 scenarios 7-12, 7-16
importing (continued) visual models 65-26
Improve Booby Trap dialog box 31-24 Improve Booby Trap task 31-24 Improve Breach dialog box 31-25 Improve Breach task 31-25
Improve Bridge dialog box 31-25 Improve Bridge task 31-25 Improve Ditch dialog box 31-25 Improve Ditch task 31-17, 31-25
Improve Fortification dialog box 31-26 Improve Fortification task 31-26 Improve Obstacle dialog box 31-26 Improve Obstacle task 31-26
improve-script-id parameter 32-21
improving
improvised explosive device, placing 28-16 inactive, tactical graphic 39-19, 40-3 including XML files in earth files 57-5 increasing speed of navigation 49-28 incremental compiling 6-12
independent mode, tutorial 4-9
independent setting, global and observer 4-24 independent task 25-1, 26-3
index
extended label, changing 18-19 indicator 18-13
Indirect Fire dialog box 31-27 Indirect Fire page 10-3, 10-6 Indirect Fire Settings page 10-7 Indirect Fire task 31-27
indirect fire weapon system 72-14 indirect-fire-actuator 72-14
indirect-fire-controller 72-14
indirect-fire-weapon-controller 72-14
individual-lifeform-param parameter 69-12
individual-lifeform-state-repository 69-12 information
Information dialog box 18-3, 18-29 centering observer from 49-26
information dialog box, configuring 79-3 information message B-4 informationitem, element 79-4
informationpagecollection, element 79-3
ingress-points parameter 73-6 inheritance, element definition 81-21
Initial Scenario Information dialog box 7-3, 7-11 Initial Unit State 24-6
initialization string, FOM Mapper B-6 initial-road-preference parameter 34-28 input
port and port group 69-14 inserting, altitude point 53-5 inset view 51-2
instrumentPanelCategory parameter 51-7 Intel Collection Area 39-9 intelligence object 8-8
intensity, rain and snow 11-12 interaction 3-12
Interest Management Settings page 6-9 interface
intermediate contour line 53-9 intersection, KD trees 5-5 intersector line, terrain 61-12 Intersector Settings page 61-12 interval
enabling and disabling 46-10 entity 46-3, 46-4
information 46-11 object
pinning object to simulation object 46-10 point-to-point 46-3
terrain profile 46-12 terrain profile line 54-6 types 46-3
Intervisibility Settings page 46-6, 46-7, 46-9, 46-
invalid model definition 81-18 invert pattern 36-22
Invert Selection check box 36-23 inverting condition parameter 36-22 Invulnerable dialog box 34-25 Invulnerable set data request 34-25 IPV6 5-9, B-8
Issue Plan, command 36-34 itemname, attribute 79-2, 79-6
Jam Targets set data request 34-25 jammer
jamming
jamming-defense-factor parameter 23-17
jam-strength-factor parameter 23-18
jitter, camera 49-27 joining exercise, late 3-7 joystick 19-18
Joystick Configuration page 75-4, 75-6, 75-7
deleting mapping 80-7 filtering function list 80-9
Key Mapping Editor page 80-4, 80-9 key value pair, reader writer 67-26 keyboard 80-2
attaching to objects from 50-3 changing speed 49-30
keyboard (continued) control 78-9
creating selection group from 17-9 entity control, configuring 75-2 inset views 51-2
key-names, location of configuration files 76-3 keyword
tactical graphic property 65-55 KilometersPerHour updater 83-12 kinetic power domain 72-18 kneeling 34-31
-L command-line option 5-5, 5-10, 7-18
-l command-line option 5-5, 60-5
label 15-3 2D
showing and hiding 18-15 entity 18-14
enabling and disabling 18-13 extended 37-3
object 15-5, 18-14, 37-3, 37-9
pinning to display 18-13 simulation object 15-5, 18-14
Lambert Conformal Conic, coordinate system 49- 7
Land at Airport Near Location task 27-12 land attack, missile 31-6
landing
fixed-wing entity 26-26, 26-29, 27-7
landing (continued)
rotary-wing entity 27-26 language
Lase Autonomous dialog box 34-25
Lase Autonomous set data request 9-16, 34-25 Lase Target task 9-16, 28-12
laser
synchronizing between entities 9-16, 34-43
Laser Code set data request 9-15, 9-16, 34-26 laser guided missile 72-13
Last Clicked Location Panel 53-16
Last Clicked Object Panel, centering observer from 49-26
lateral-clearance parameter 73-4
Launch Anti-Submarine Missile (Vertical) task 28- 12
Launch Counter Measures, task 9-19 Launch Smoke task 28-13
launcher controller 72-13 launching
torpedo 28-14 layer
earth file
adding 52-4, 55-11 adding prop from 55-22
adding 55-16 layout
default, clearing 78-6 formation
leader-promotion-id parameter 73-3
leaf file, importing 81-34 leaf files, importing 81-33 length
intervisibility object 46-8 simulation object name 15-4 track history 42-6
level, notification for messages 5-16 level observer 49-7
level-of-detail 49-18, 49-19, 83-22
See also LOD library, dynamic 4-31 license
License Manager 2-5 license server, hostname 2-6
License Setup dialog box 2-6 lifeform 35-12
configuring DI-Guy appearance and character 68-3
Lifeform Surrendered condition 35-12
lifetime
radio communication line 42-22
squawk indicator and communication line 42- 22
light
light characteristic attribute 57-31
light_layer_list.csv 57-29 lighting
Lighting Render Settings page 43-4, 43-5
limitation, terrain 55-4 limited munition attack 23-7 line
changing width 39-17 creating
displaying terrain profile 39-6 opening terrain profile 54-3
direction, changing 39-16 dotted and dashed 39-17 editing 39-17
opening terrain profile 54-3 fire 42-9
height-above-terrain 18-23, 37-6
suppressive fire at 26-32, 28-17
vertex, showing in terrain profile 54-3 Line Width dialog box 40-5
Line Width set data request 40-5 linear feature, list of 53-14
line-of-sight
See also intervisibility communication line 42-22
terrain profile 46-12 unit versus entity 23-8
linked event, adding 8-6 lisp C-2
list
clearing Categories, Used by Countries, and Favorites 65-9
Used By Countries 65-9 vector feature 53-14
listing, components in OPD 69-16 LITCHR attribute 57-31
Little Pond terrain 53-19 load balancing 7-19
Load Batch File dialog box 7-39 Load Overlays dialog box 38-5
Load Scenario dialog box 7-17, 7-19
load-entry-point parameter 73-6 Loader Settings page 61-11 loading
display engine configuration 5-3, 77-5
entities on entities 19-7 entity display settings 5-4
multiple DTED files 57-6 object type mapping 5-4
plug-ins 4-32, 4-33, 5-3, 5-5, 5-6, 5-10, 5-17
from command line 5-7 paged 5-10
loadPluginIfVersionMismatch parameter B-4
local
Local Weather Zones page 11-13 locale, specifying 5-4
local-objects parameter 69-9, C-4 localSettingsDesignator parameter B-6 location
fixed-wing at creation 26-23 jumping to 49-16
ordering simulation object to 27-16 setting 16-3, 34-26
by dragging 16-19 suppressive fire at 26-32 window 77-6
Location dialog box 34-26 location image attribute 55-9 Location set data request 34-26 Location3D class 33-18
locking
LOD 49-18, 49-19, 83-22, 83-26
ocean elevation 55-16 paged, scale factor 49-20 scale, setting 43-10 terrain, zooming in 49-21
LOD distance, buoyancy 44-7 log file 4-38, 5-11, B-3
frame rate statistics B-3 messages sent to 5-16
sending entity messages 18-35 specifying 5-5
vrfSim 5-11 logFrameRateStatistics parameter B-4 Logger
recording view control messages 36-35 Logger Control message 7-40
logger-files-path parameter 7-38
resupply, starting or stopping 34-42 resupply modes 34-35
longitude 18-10, 33-18 Lower Periscope task 30-12 Lua 32-3, 32-5
locations and vectors 33-18 method 33-3
script, extended name 32-12 table 33-15
tasks and subtasks 33-15 utility functions 33-6 vector
lua
global variables, saving 33-14
Lua API Documentation 33-3, 33-15
lubricants, pacing and tracking 34-21 LWO file 52-3
-m command-line option 60-5 magnification, performance 49-21
mainmenuconfiguration, element 79-2 MÄK Encrypted Data Format 60-7 MÄK RTI, configuring 2-9
MÄK Technologies LISP A-3 MAK_EARTH_FILE attribute 62-4 MAK_GEOID_GRID, environment variable 55-
MAK_SOURCE_FILE attribute 62-4 MAK_VRF_ENABLE_DEBUG_DRAWER,
environment variable 56-8, 56-9
Makland terrain 53-19 MAKLMGRD_LICENSE_FILE, environment
Manage Reactive Task dialog box 26-17 Manage Reactive Tasks dialog box 21-10 managing, plug-ins 4-31
manual
aggregation and disaggregation 24-12 conventions lvii
location of 2-4 map
map datum, configuring B-6 Map Scale Toolbar 53-17 mapping
joystick keyboard controls 75-7 keyboard 49-11
keys 80-3 model
to remote observer 48-12 movement to keyboard 49-10 object type 82-4
shapefiles to features 55-11 soil types 61-13
sound effects 47-4 sound file to entity 47-5
marine
effects, enabling and disabling 11-17 marker, system 65-31
Marker Labels, check box 65-31 Marker Labels check box 65-25 marker-scale attribute 83-24
marking, remote simulation object 35-19 marking text 18-10, 65-7
mask
adding to earth file 57-14 element 57-14
matching object type 69-6 material, ambient value 43-4 Max Sheaf Radius 31-27
max-detonation-distance-for-passing-rounds parameter
maxDrainInputReads parameter B-7 maxDrainInputTime parameter B-4 maximum sheaf parameter 67-12
max-range-altitude parameter 28-19
max-thrust parameter 26-28 mcastTtl parameter B-7 MEDF 60-7
media, adding to scenario event 8-5 MEIF, creating 83-27
improving use of 6-11 menu
menuname, attribute 79-2 merging
information and warning B-4 notification level 5-6
object console, sending 36-33 radio 30-7, 30-9
between front-end and back-end 3-3 text 30-10
message (continued) view control 49-34
message-timeout parameter 13-3 metadata
in system definition file 69-17 script 32-5
metafile, texture skinning 83-19, 83-20
metaFileName parameter 83-19, 83-20, 83-21 MetaFlight
building efficient terrains 60-2 loading 56-5
middle-click menu 78-9 migrating
object parameter database to new release 69-27 SMS 64-13, 64-14
Military Scenario Definition Language, importing 7-14
Military Symbol Icon, visual definition 83-2 MIL-STD 2525B color 19-26
Mimic Location Track mode 50-10 Mimic mode 49-8, 50-7, 50-9 Mimic Track mode 50-10 mimModule parameter B-6 minDrainInputTime parameter B-6 mine
minefield, creating 31-20 minimum lift speed 26-28 minimum tick period 6-13 minimum tick period variance 6-13 min-tick-period parameter 6-13
min-tick-period-variance parameter 6-13 mirror image attribute 55-8
missile (continued) laser guided 72-13
Missile Approach Warning condition 35-12 missile attack 23-7
missile controller 72-12, 72-13
missile launcher system 72-11 Missile Target, page 10-8, 10-10 missile target event 10-10
missile-collision actuator 72-12, 72-13
missile-entity-state-repository 69-12
missile-maneuver actuator 72-12, 72-13
missile-param parameter 69-12, C-8
Mission Oriented Protective Posture. See MOPP mobility, modifier 23-9
mode
view 49-8, 50-7 model
hiding 19-26 adding
calculating support point from 65-12 colorized, changing 65-20
model (continued) decal effects 42-4
DI-Guy, choosing 68-5, 82-10 editing model mapping 82-5 element 57-7, 57-8, 83-24
flipping DDS textures 83-21 illumination 11-4
layer, filtering 53-12 mapping
to remote observer 48-12 name 18-10
vehicle 1-7 visual
refreshing 65-27 model definition
building from attributes 57-24 texture atlas 57-27
model definition (continued) deleting 81-13
exporting 65-27, 81-20 filtering list of 81-15 importing 65-26, 81-19
importing from command line 81-19 invalid 81-18
merging 81-19 parameter
tactical graphic texture 65-56 texture atlasing 83-19
Model Definition Editor page 81-9, 81-12, 81-13,
81-14, 81-15, 81-17, 81-18, 81-20, 83-
9, 83-19, 83-21, 84-5, 84-6, 84-7
Model Specification for DIS Interoperability 85-2
modeldefinitionschema, attribute 83-6 modeling
combat engineering object 23-9 mobility 23-9
modifiers 67-17 modifying
sensor signature 39-9 module
monitor, multiple 77-17 monitoring, entity resources 18-29
MOPP Level dialog box 34-27 morale, setting 34-27
Morale dialog box 34-27 motion, file 68-4
mouse
drag view 49-15 locking to object 16-18
moving observer 49-14, 49-15, 49-18
Mouse Mappings page 49-14, 49-18 Move Along Route dialog box 27-13 Move Along Route Retrograde task 31-28 Move Along Route task 27-13
Move Into Formation dialog box 27-14 Move Into Formation task 27-14
Move to Altitude dialog box 27-15 Move to Altitude task 27-15
Move to Depth dialog box 27-15 Move to Depth task 27-15
Move to Location (Plan Along Roads) task 26-22, 27-18
Move to Location dialog box 27-16 Move to Location Retrograde task 31-28 Move to Location task 27-16
Move to Waypoint (Plan Along Roads) task 27-21 Move to Waypoint dialog box 27-20
Move to Waypoint Retrograde task 31-28 Move to Waypoint task 26-22, 27-20 movement
speed, affect of posture 23-5 speed scaling 49-28
task, affect of aggregation and disaggregation 24-10
movement file, configuring 65-51 movement parameter 67-19 movement system
properties, editing 67-20 moving
along a route 27-13 articulated parts 30-11
mouse with 49-14, 49-15, 49-18
to points or simulation objects 27-20 vertex 39-14
moving-object-param parameter 69-12, C-8 moving-object-param parameter type C-8 MSDL, importing 7-14, 7-16, B-4
MTD file 52-3 MTL file 52-3, A-3
multicast address, configuring B-7 multicast mode, specifying 5-20 multicast time-to-live 5-20, B-7 multichannel, configuring 77-17
MultiGen-Paradigm, OpenFlight format 85-2 multimedia, adding to scenario event 8-5 multiple
parameter values 81-29 simulation model set 7-8 VR-Forces processes 3-2
multiple entity creation 21-5 specifying entity type 21-8
Multiple Object Information window 18-9 munition, display of path and detonation 42-9 munition block 72-18
Munition Target Settings dialog box 10-3, 10-6, 10-8, 10-10
mutually exclusive task 25-1, 26-5, 35-7
mutually-exclusive-task-groups parameter 26-35
-N command-line option 5-7, 5-8, 5-12
-n command-line option 5-6, 5-11, 5-16
name 15-3 changing
feature layer, specifying 62-2 FED file B-6
simulation object 15-4, 18-9, 65-7
Naval Depth Charge Deployment, system 28-4 Naval Mine Deployment, system 28-5, 28-6 naval mine explosive device system 72-16 navigating
view 49-3 navigation
attached context 49-8 function, editing key map 80-4 key map 80-2
navigation (continued) speed scaling 49-28
navigation area
cancelling generation of navigation data 58-7 configuration file 58-10
generating navigation data for 58-6 importing 58-10
Navigation Areas page 58-3 navigation data 3-12, 58-2
removing from queue 58-7 generating for entity 58-9 importing 58-10
Navigation Lab 58-11 debugging B-3
viewing simulation objects in 58-13 Navigation Preferences set data request 34-28 navigational aid light 57-31
navigation-preference parameter 34-28
NBC
sending 31-29 near clipping plane 77-9
Near Far Clip Policy, attribute 77-10
net-interface-min-tick-period parameter 6-14, C-5, C- 7
net-interface-min-tick-period-variance parameter 6-14,
network
connecting to, automatically 5-3 vector 26-22
network interface C-5 hierarchy 69-12
network-interface parameter C-5, C-7
new
New Scenario dialog box 7-35, 12-3
night-illumination parameter 71-13 no dialog box 5-15
non-VR-Forces, simulation object 35-19 normal map 1-15, 61-7
notification, icon 18-35 notification level 5-11, B-4
setting for entity console 18-32 specifying 5-6
Notify Level dialog box 34-28 Notify Level set data request 34-28
tactical graphics 40-5 notifyLevel parameter B-4 Nuclear Attack dialog box 31-29 Nuclear Attack task 31-29
nuclear contamination 23-7, 23-8, 31-29
-O command-line option 5-6 oberver, camera shake 49-27 OBJ 80-5
file 52-3 object
adding
resources in OPD Editor 70-11 to Props Palette 16-26, 81-10
to selection group 17-9, 17-10
altitude, changing 19-5, 39-13 attaching observer to 50-2 category, changing 65-3 changing
configuring, avoidance of 73-5 control 37-2
creating 16-3, 16-4, 16-5, 16-8, 16-9, 16-11
object (continued)
creation, mouse locking 16-18 cultural feature 16-26, 65-9
deleting from simulation model set 65-34 detaching observer from 50-5 disembarking 34-17
to new location 34-26 editing 39-12
embarking in Embarkation View 19-10 enabling and disabling creation of 65-7 entity enumeration, changing 65-4 exaggerating models 19-23
fill style 39-17 filtering list of 17-6 geometric 33-18
pinning to simulation object 46-10 label 15-5, 18-14, 37-3, 37-9
location, changing 19-5, 39-13 locking mouse to 16-18
object type, changing 65-4 orbiting 49-13
placing 16-11 properties
object (continued) properties
in Objects List Panel 17-6 selecting in multiple list box 26-8 showing and hiding 37-8 subcomponents 69-9
super-type 69-5 timeout threshold B-7 type 69-4
unselecting 17-7 vertex
notification of messages 18-35 setting notify level 18-32 warning icon 18-35
Object Console Summary Panel 17-4, 18-33, 33-
answering questions 18-34 selecting simulation object 17-6
object geometry, adding 65-14 Object Group category 16-25 object map file 6-1, 12-2, 12-9
object parameter database 3-8, 64-5, 69-2 adding, component in OPD Editor 70-8 component list order 69-16
configuring, sensors 71-2 configuring path to B-3 loading in OPD Editor 70-3 migrating to new release 69-27 pathname interpretation 69-26 reloading B-3
Object Parameter Database Editor. See OPD Editor
object type enumeration C-9 object type mapping
objectConsoleNotifyLevel parameter 18-32 objectConsoleNotifyLevel parameter B-4 Object-Map parameter 12-5
Objects Console Summary Panel 18-3
Objects List Panel 17-2, 17-4, 17-6, 19-7, 19-10,
Embarkation View 19-7 selecting object in 17-6
OBJNAM, attribute 57-26 objTypeEnums.h header file C-9 observer 49-3
altitude, filtering simulation objects by 6-9 attaching
to simulation object or prop 50-2 to simulation objects 50-6
attachment
centering on object from Information dialog box 49-26
centering on object from Last Click Object Panel 49-26
centering on object from Object Console Summary Panel 49-26
compass 49-4 coordinate system
detaching from object 50-5 dragging
heading 49-4 inset view, in 51-2
location and orientation 49-3 LOD, ocean 55-16
observer (continued) mode 48-2
switching projection 48-2 view control message 36-35 XR 48-10
speed 49-30 moving
rain and wave effects 44-2 range for sound effects 47-3 removing 48-9
teleporting 49-16 view
ways to move 49-12 zooming 49-18
entity extents 49-22 zooming to extents 49-22
Observer Control Panel 49-28 Observer Information Panel 49-3 Observer Name 77-7
Observer Settings page 18-26, 18-30, 18-31, 19-
25, 19-26, 42-4, 42-5, 42-14, 43-7, 44-3,
45-4, 48-4, 48-5, 48-6, 48-9, 49-5, 49-
Observer Views Panel 49-31 loading saved views 49-33 saving views 49-33
configuring avoidance of 73-4 destroying 31-23
obstacle (continued) linear 37-2, 37-5
obstructed terrain, viewing in terrain profile 46-12 obstruction, configuring avoidance of 73-4 occupancy-director-controller, role in embarkation
dynamic, enabling and disabling 11-17 effect 11-16
height 55-15, 55-16 height map
Ocean Height Map Regeneration Threshold 55-19 ocean height map resolution 55-18
Ocean LOD Elevation 55-16, 77-16
Ocean Settings page 11-20, 43-9, 43-10, 43-14,
off road driving 26-22 offset
pacing and tracking 34-21 setting 34-20
opacity
opacity (continued) prop 55-25
setting 55-25 OPD, reloading B-3 OPD Editor 1-18
changing, component priority 70-9 compared to Simulation Object Editor 64-3 connecting components 70-10
deleting parameters and components 70-7 editing, parameters 70-4
loading object parameter database 70-3 opening from Simulation Object Editor 65-31 restoring values 70-7
saving object parameter database 70-12 starting 70-2
Open Cargo Door task 30-13 Open Door task 29-6
Open Model Set dialog box 64-7, 64-16 Open Window task 29-6
converting texture data 61-13 file 52-3
opening
Create Object dialog box 16-13 door 29-6
simulation model set 64-16 terrain 52-7
environment variables for anaglyphic stereo 77- 21
license 1-22 operator
optimizing, performance 6-4 option
Orbit task 27-23 orbiting
terrain, with mouse 49-15, 49-18
default values in 12-10 ordered speed, setting 34-29 Ordered Speed dialog box 34-29
Ordered Speed set data request 34-29 fixed-wing for 34-29
Order-Of-Battle parameter 12-5
ordnance
unexploded, destroying 31-22 organization
observer 49-3, 49-14, 49-15, 49-18, 50-7
specifying measurement unit 78-11 OSG file 52-3
OSG_CURL_PROXY, environment variable 56- 5
OSG_CURL_PROXYPORT, environment variable 56-5
OSG_ICO, environment variable 6-12 osgEarth 1-19, 56-2, 57-3, 61-14
adding terrain servers 56-4 driver 57-6
osgEarth Boundary Generation Tool 57-14, 57-16 osgEarth Profile dialog box 61-14
osgearth_cache 1-18, 61-5 OSGEARTH_CACHE_PATH, environment
variable 61-3 OSGEARTH_CURL_PROXYAUTH,
outline
emitter volume segment 84-6 segment 84-6
Out-the-Window, observer mode 4-24 out-the-window view 77-17
overlay (continued) creating 38-3 default
editing, enabling and disabling 38-3 export to shapefile 38-6
by default 38-4 hiding graphics on 37-8
importing shapefile to 38-7 introduction to 38-2
locking and unlocking 38-3 moving objects between 39-5 object 37-2
Overlay Layers dialog box 65-8 overlay object
disaggregation area 24-12 moving, to different overlay 39-5 pasting 16-21, 16-22, 16-23
Override Position 19-9 overriding
default scenario parameters 7-5 plan 36-42
-P command-line option 5-9, 5-13, 5-20
-p command-line option 5-8, 5-13, 60-5 pacing
package, scripted task 32-32 page
page (continued)
Checkpoint Settings 7-26, 7-32, 7-33, 7-34
Date and Time 11-3, 11-4 Detonation Sound Editor 47-9 dialog box, configuring 79-3 DI-Guy Settings 6-20
Display Units Settings 18-23, 37-10
Edit Existing Props 55-21 Elevation Color 53-4, 53-5, 53-6
Engineering Object Information 23-12 Entity Behavior Options 24-6, 24-11
Entity Definition Editor 83-2, 83-15, 84-7
Entity Sound Editor 47-5, 47-6, 47-7 Environment Conditions Settings 83-17 Feature Settings 53-15
High Dynamic Range Settings 43-11, 43-16
Joystick Configuration 75-4, 75-6, 75-7 Local Weather Zones 11-13
Model Definition Editor 83-9, 83-21, 84-5, 84-
Resource Information 18-29 Scenario Event Settings 8-14 Schema Editor 81-12
Session Options 18-18, 18-19, 78-10
Symbol Decoration Settings 18-16 Tactical Graphics Settings 39-19 Terrain Contents 55-15
Weather 11-6, 11-7, 11-8, 11-9, 11-10, 11-11,
Paged LOD Magnification LOD Angle 49-21 Paged LOD Magnification Scale Factor 49-20 paged terrain
flipping DDS textures 61-11 loading 5-10
paged terrain (continued) preprocessing 56-6
paging
manually 56-6 palette
Hazards/Obstacles 11-14, 16-4, 16-5, 23-9
Tactical Graphics 16-5 panel
displaying and hiding 78-3 dockable 78-2
Frame Rate Monitor 6-5 Last Clicked Location 53-16
Object Console Summary 18-33 undocking 78-2
parachuting 34-31 parameter
acceleration-to-rpm-factor 9-18
adding, to model definition 81-15 additional-algorithm-config 72-29 additionalDestinationAddresses B-7 additional-opds 12-6 additionalSystemScriptsDirectory B-2 addMulticastAddr B-7
aggregate-formation-controller 73-2
aggregateSpatialModelTickAsFastAsPossible-
WhilePaused B-2 aggregateSpatialModelTickPeriod B-2 aggregateSpatialModelTickPeriodUsesRealTime B-2 aggregateSpatialModelTickVariance B-2
allowed-state-repositories-types 72-32
angle-of-incidence 72-22, 72-26
angleSegmentMax 84-5 appIdRange B-7 appNumber B-2
assertOnBlockingTerrainCalls 52-8, B-2
Attach Components to Remote Entities On 7-5 attack, editing 67-22
auto-reorganize 12-5 batchScenarioFileName B-2 can-be-radar-jammed 23-17
catastrophic-kill 72-26 cgfDispactherReceivePort B-2 ChannelKeyword 83-12 commenting out A-3
Component Attachment Table 7-6 component list order 69-16 Component-Attachment 12-5
Component-Attachment-Table 12-5 component-manager C-5, C-7 configName 83-19, 83-21 countryCodesMappingFile B-2, B-4 Create_Global_Dynamic_Terrain 12-6
Create_Global_Environment 12-6
cultural-feature-param 69-12, C-8
daemon B-2 datumShiftX B-3 datumShiftY B-3 datumShiftZ B-3
day-night-transition-time is 71-13 defaultHeartbeatThreshold B-7 defaultObjectTimeout B-7 DefaultObserverView 12-6
defaultParameterDatabasePath 12-7, B-3
defaultTerrainDatabasePath 12-7, B-3
delay 72-29 deleting
from model definition 81-18 in OPD Editor 70-7
detonation-on-destroy 72-29 deviceAddress B-7 diGuyAnimationsFile B-3 DIS B-7
Display Terrain 7-6 disPort B-7 doNotUseConsole B-3
editing in Simulation Object Editor 65-12
electronic warfare, editing 67-23
embarkation-slots 73-6 enableDebugDrawer B-3 enableLogFileTimestamps B-3 enableNavigationLabDebugging B-3 entity-range 72-9
exercise-start-time 12-6 federateName B-6 federateType B-6 fedFileName B-6 Filename 83-11
fixed-wing-entity-param C-8 fomMapperInitData B-6 fomMapperLib B-6 forceParameterDbReload B-3 Frame Mode 7-7
time management 4-18 frameRateStatisticsLogFile B-3 frame-time 12-6 gamewareMemorySize B-3 ground-vehicle-param 69-3 ground-vehicle-param C-8 guidance-mode 72-18
Gui-Terrain-Database 12-5 heartbeatVariance B-7 HLA B-6
parameter (continued)
load-entry-point 73-6 loadPluginIfVersionMismatch B-4 local-objects 69-9, C-4 localSettingsDesignator B-6 logFrameRateStatistics B-4 logger-files-path 7-38
max-detonation-distance-for-passing-rounds 26-34
maxDrainInputReads B-7 maxDrainInputTime B-4 maximum sheaf 67-12
max-thrust 26-28 mcastTtl B-7 message-timeout 13-3
metaFileName 83-19, 83-20, 83-21
mimModule B-6 minDrainInputTime B-6 min-tick-period 6-13
model definition, editing 81-15, 81-17
movement 67-19 moving-object-param C-8 munition-type 72-37
mutually-exclusive-task-groups 26-35
net-interface-min-tick-period 6-14, C-5, C-7
net-interface-min-tick-period-variance 6-14, C-5, C- 7
parameter (continued) object 69-3, C-3
objectConsoleNotifyLevel 18-32 objectConsoleNotifyLevel B-4 Object-Map 12-5
parameter-type 69-3, 69-8, 69-12, 69-26, C-2,
plan-manager C-5, C-7 pluginsDirectory B-4 position-offset 73-3
providing information to components 15-8
publish-transmitters 74-4 publishZeroVelocityWhenPaused B-4 Radio Button Choice 32-15 Random Number Seed 7-7 random-number-seed 12-5
recvBufferSize B-8 rejectMismatchedScenarioMessages B-4 relative-heading 19-14
remote-objects 69-9, C-6 reuseEntityIdentifiersOnScenarioLoad B-4 rotary-wing-entity-param C-8
round-down 72-22 rprFomVersion B-7 RSOName 83-11
runInTimeManagementMode 4-19, B-7 scenario
ScenarioExtentInformation 12-6
Scenario-Extras 12-5 scenarioFileName B-4 scenario-filename 7-38
Scenario-Scripts 12-5 schema
SelectionGroups 12-5 sendBackendLogToNetwork B-4 sendBufferSize B-8 sendFedTime B-7
send-spot-reports-on-own-force 9-7
sessionId B-4 setDeadReckoningAlgorithmToStaticOnPause B-5 setMainThreadToHighPriority B-5
setting simulation object 34-4 showLines 84-6 simMgmtPduProcessLevel B-5 Simulation Model Sets 7-6 Simulation Object 32-16
Simulation Terrain 7-5 simulationModelSet B-5 Simulation-Model-Set-Files 12-6
soil-list 19-17 specifying for task 26-7 speed-to-rpm-factor 9-18 spheroidSemiMajor B-5 spheroidSemiMinor B-5
standard-terrain-damage-type 72-28
state-repository-min-tick-period 6-14
state-repository-min-tick-period-variance 6-14
statusUpdateHeartbeat B-5 stopping-distance-factor 73-4 structure of entries C-2 subnetMask B-8
substitute-message-size 13-3 subsurface-entity-param C-8 sunrise-time 71-13
suppression-degrades-sensor-performance-by 26-35
suppression-detonation-insult 26-34
suppression-detonation-range 26-34
suppression-insult-level 26-34
suppression-recovery-time 26-34
suppressSelfReflect B-8 surface-entity-param C-8 targetFrameRate B-5 targeting-capable 34-18
task-manager C-5, C-7 taskVisualizationPublicationMode B-6 terrain-check 26-31
Terrain-Database 12-5 terrainDatabase B-6 Time Multiplier 7-6
underFireTime 34-36 useAbsoluteTimeStamps B-7, B-8 use-actual-message-size 13-3 useAdvisories B-7
useAsyncIO B-8 useCustomMapDatum B-6 useDIGuy B-6
useDrawControlForTaskVisualizations B-6
using remote entities as 35-19
value, restoring in OPD Editor 70-7
parameter (continued)
visual definition, editing 81-29
vrf-base-object-param 69-26, C-3
parameter-type, control object 69-26
parameter-type parameter 69-3, 69-8, 69-12, 69-26,
parent
parent, attribute 83-6 particle effect, sea spray 44-4
passing-rounds-suppress parameter 26-34
passive sonar 9-17 paste
Paste Special 16-23 pasting
patch, terrain 52-3 path
planning 3-14, 27-18, 27-21 using road data 34-28
specifying for RTI 2-9 pathname
interpreting by object parameter database 69-26 scenario files 12-7
Patrol Between dialog box 27-24 Patrol Between task 27-24 Patrol Route dialog box 27-23 Patrol Route task 27-23 patrolling
route 27-23 pattern
pattern (continued)
Pattern Hold (Location) dialog box 27-24 Pattern Hold (Location) task 27-24 Pattern Hold (Waypoint) dialog box 27-25 Pattern Hold (Waypoint) task 27-25 Pattern tab 36-24
pause
scenario, using PDU 7-41 pause mode B-5
pausing
scenario, automatically 7-7, 7-35
simulation 7-25 PDU
siman, configuring B-5 Start/Freeze 7-41
pedestrian area 21-9 adding entities to 21-3 adding pedestrians 29-3
control object 21-9, 37-2 pedestrians, adding to crowd 29-3 pen style 39-17
Pen Style set data request 40-6 Percent Complete dialog box 34-29
Percent Complete set data request 34-29 performance 6-8, 6-9, 6-14, 49-19, 55-17
affected by copy and paste 16-21 anti-aliasing 5-3
attached observer 50-6 coloring draw calls 6-18 compressing texture 61-6 cube map calculation 43-14 DI-Guy 6-19
performance (continued) interest management 6-8
model, best practices 83-26 network, tuning 6-15
ocean planar reflections 43-10 optimizing 6-3, 6-4
setting application priority 5-4 shadows 43-21
terrain 55-4 tuning
visual for 3D application 6-15 visual 6-19
Performance Options dialog box 6-15, 6-16
Performance Options page 6-15, 6-17
period, burst 20-8 periodic checkpointing
periodic snapshot, enabling 7-34 periscope
permanent intervisibility object 46-5 personnel, status 18-7
personnel parameter, editing 67-24 perspective, in display 77-14 Perspective parameter 83-11
PerspectiveHeight parameter 83-12
PerspectiveWidth parameter 83-12
phase line 37-2, 37-4 Entity Left of Line 35-12
physicalWorldParams.mtl, file 71-9 pinning
sensor contact lines 42-14 task visualization 42-13
Place IED task 28-16 placing 16-11
tactical graphics 16-11 plan
confirmation prompt 26-6 from a plan 36-42
adding
assigning to multiple simulation objects 36-39 concepts 34-1
conditional statement 35-4 considerations for creating 36-3 console message, sending 36-33 copying 36-40
default 20-2, 20-9, 20-13 deleting
drag and drop statement 36-40 editing 36-3
Follow Entity task 35-18 force hostility 9-12
global command, adding 36-30 global task, view control 36-35 including scenario events 8-11 individual 11-2
inverting condition parameter 36-22 issuing 36-34
plan (continued)
name in condition 36-23 pasting 16-22, 16-23 pattern in condition 36-24 printing 36-10
remote simulation object 35-19, 36-39
simulation time condition 35-13 Tasked by Superior 35-18 trigger 35-7
Plan window 35-16, 36-3, 36-4, 36-5, 36-6, 36-7,
plan-manager parameter C-5, C-7 planning, path 3-14, 27-18, 27-21
plant, avoiding 19-16 platform
platform file 69-16 variable binding adding 69-22
adding to Simulation Object Editor 69-23 variable bindings 69-21
platoon, preconfigured 24-5 playing, scenario event 8-10 plug-in
configuration, deleting 4-36 DLL
loading 4-32, 4-33, 5-3, 5-5, 5-6, 5-10, 5-17
Plug-ins Editor 4-32, 4-34, 4-35, 4-36, 4-37
pluginsDirectory parameter B-4 PNG 52-4
civilian visit 21-9, 21-10 feature, list of 53-14 moving to 27-20
suppressive fire at 26-32, 28-17 terrain profile, sampling rate 54-3
point feature, in front-end and back-end 52-5 point-to-point communications
configuring B-7 specifying 5-20
point-to-point intervisibility 46-3
configuring 77-22 policy
Distance To Attached 77-10 Reduce Near Clip 77-10 Reduce Z Fighting 77-10
not going through 49-28 terrain, viewing 53-18
for scenario files B-2 group 15-8, 69-14 number B-7
specifying at startup 5-20 proxy 56-5
specifying, at startup 5-20 position 49-3
position-offset parameter 73-3 posture
affect on footprint, sensing, sensor signature, speed 23-5
posture (continued) changing 31-11, 34-30
transition time, editing 67-21 Travel 23-4
Posture dialog box 34-30, 34-31
Posture set data request 34-30, 34-31 power
power-plant-active parameter 9-18
precedence, components in OPD 69-16 precipitation 11-5, 11-8
preferred movement mode 29-7 preferred road data 29-7
Preferred Targets dialog box 34-32 preprocessing
terrain, paged 56-6 primary color, unit 25-11
primary simulation object 50-10, 50-13 printing
window 4-13 priority
probability table, direct and collateral damage 72- 10
probability-coefficient list 72-9 process
background 33-30 object mappings to 12-9 VR-Forces 3-2
process ID, front-end 5-9 processing
streamed data 57-7 product
technical support lvi upgrades lvi
profile, navigation data 58-6 profiler, function 6-8 projected terrain database 49-7 projection
supported 1-13 switching 2D to 3D 48-2
Projection Resize Policy 77-7 configuring 77-11
promotion-id parameter 73-3 prompt
confirmation, abandoning plan 26-6
task confirmation, enabling or disabling 26-6 prone 34-31
adding
to Props Palette 16-26, 81-10, 83-13
attaching observer to 50-2, 50-6
creating 16-3, 16-4, 16-5, 16-8, 16-9, 16-11,
from terrain 52-4 filtering attachment list 50-5 heading, setting 16-17
model definition, changing 55-26, 63-23
viewing list of 55-24 property
tactical graphic, default 65-54 window 77-6
Props Palette 16-3, 16-4, 16-5, 16-11
adding objects to 16-26, 81-10, 83-13
Props Palette (continued) category, adding 83-14
propulsion noise 9-17, 9-18 Protest Along Line dialog box 29-7 Protest Along Line task 29-7
Protest Around Location dialog box 29-7 Protest Around Location task 29-7 protesting, crowd 29-7
Provide Suppressive Fire on Location task 26-32, 28-18
Provide Suppressive Fire task 26-32, 28-17
proximity sensor 72-16 proxy
port 56-5 pruning
model definitions 65-26 object type mappings 65-26 visual models 65-26
published object type 69-6 publishing
entity velocity when paused B-4 radio trasmitter 74-4
publish-transmitter parameter 74-4
publish-transmitters parameter 74-4 publishZeroVelocityWhenPaused parameter B-4 pulse repetition rate 84-2
-q command-line option 5-11 Qt Designer 69-23
UI file, details 69-24 Qt Linguist 2-10
quality, ocean 11-20 query
named 62-3 question
asking from script 33-23 scripted task 18-34
Quick Launch toolbar 8-10 quitting
quitting (continued) retask procedure 26-7
-r command-line option 5-11, 60-5
sensor 34-18 radar mode
Radar Mode dialog box 34-33 Radar Mode set data request 34-33
Radar-Jamming-Strength-Receiving 23-17
enabling and disabling 42-21 lifetime 42-22
configuring 74-4 message
set data request 30-7 task 30-9
Radio Button Choice parameter 32-15
Radio Communications Settings page 42-21, 42-
radio transmitter, publishing 74-4 radius
Raise Periscope task 30-13 random
Random Number Seed parameter 7-7 randomized simulation object 65-43 random-number-seed parameter 12-5 range
Simulation Time Scale Toolbar, changing 7-25
configuring display of 18-27 displaying for entity 18-26 enabling and disabling 18-26 pinning 18-26
Range Rings Settings tab 18-27 range-coefficients determinant 72-20
range-determinant parameter 72-9, 72-26
range-list parameter 72-9 raster map
Raster Maps page 55-7, 55-10, 61-7, 63-5 rate
climb, turn, and descent 27-10 turn 27-9
ray
reactive task 21-10, 26-12, 30-19, 32-5, 33-8, 33-
Visit Interest Points 21-10 reader writer key value pair 67-26 Real DB 1-21
real time
running faster or slower than 3-11 recalling
receive buffer size 5-9, 5-13, B-8 Receive Text Message condition 35-13 receiving
recently used scenario 7-18 Reconnaissance, posture 23-4 recording, to Logger 7-41 recovering, embedded entity 30-14 recovery 34-11
Reduce Near Clip, policy 77-10 Reduce Z Fighting, policy 77-10
Reduce Z Fighting Ratio, attribute 77-10 reference ellipsoid B-3, B-5
configuring B-6 reflection
refreshing, visual models 65-27 refueling boom 30-12, 30-13 regenerating
ocean height map 55-19 platform 70-12
regenerating spot report definition 65-21 region
Register Trigger dialog box 36-8 registering, triggers 36-8
registrant_feature_list.csv 57-7
regulating, time 4-17 rejectMismatchedScenarioMessages parameter B-4 rejoining exercise 3-7
relative-heading parameter 19-14
relative-position parameter 19-14
Release Bomb on Laser Spot task 28-18 Release Bomb on Location task 28-19 Release Bomb on Target task 28-19 reloading, visual models 65-27 remapping
batch mode 7-39 remote
entity, attaching components to 7-5, 76-2
stealth, displaying model 48-12 remoteAttachment example scenario 76-2 remoteConfigurations directory 76-3
remote-configurations entry 76-3
remote-objects parameter 69-9, C-6 removing
object from Favorites list 16-27 objects from selection group 17-10 observer 48-9
simulation objectfrom unit 24-8 subordinate 66-5
triggers from plan 36-9 view 49-32
window 77-5 renaming
Render Settings page 6-7, 6-8, 6-18, 43-13, 49-25,
Reorganize set data request 34-33 reorganizing
concepts for units 22-4 unit 34-33
versus closing formation 22-5 repair 34-11
repeat image attribute 55-8 replace image attribute 55-8 replacing
saved view list 49-33 subordinate 66-6
replicating, settings and data 4-23 report
require statement, Lua 33-6 Reserve Space 19-9
resizeable window 77-2 resizing
boxes and text overlay objects 39-15 windows 77-11
resolution
resolution (continued) tree 83-22
resource
adding to object 70-11 information 18-4
monitoring entity 18-29 pacing and tracking 34-34 specifying 34-34
status at creation 19-4 tracking unit 24-10
Resource condition 35-13 Resource Information, page 18-29 resource-item, adding 67-26 Resources dialog box 34-34
Resources Pacing/Tracking dialog box 34-34 Resources Pacing/Tracking set data request 34-34 Resources set data request 34-34
Restart Plan command 36-41 restarting, plan 36-41
Restore set data request 34-35 restoring
embedded entity parent 19-15 parameter values in OPD Editor 70-7
simulation object health and stores 34-35 unit 24-10, 34-35
restriction, unit movement 62-9 result
detonation, sound mapping 47-8 resuming, simulation 7-24
Resupply Mode dialog box 34-35 Resupply Mode set data request 34-35 retreat 31-28
retrograde movement 31-28 reusable software object 83-10
reuseEntityIdentifiersOnScenarioLoad parameter B-4
Reverse Direction 27-13 reversing, line direction 39-16 reverting
category changes 64-21 navigation area edits 58-5 parameter values 70-7
revolving, observer 49-13 rewinding
rewinding (continued)
to a snapshot or checkpoint 7-25 RGB 52-4
ring, range 18-24 road
data, using in path planning 34-28 driving on 26-23
network 26-22 using route as 27-13
roll up, rule 67-14 Roll updater 83-13
rolling back to a snapshot 7-25 rolling up assembly 67-15 rope, sliding down 27-6
Rotary Wing Airlift Cargo to Location task 27-25 Rotary Wing Land dialog box 27-26
Rotary Wing Retrieve Cargo task 27-26 Rotary Wing Unload Cargo task 27-27 rotary-wing, landing at airport 27-12 rotary-wing entity
altitude 27-8, 27-10 attacking with gun 28-3 creating, routes for 39-10 heading 27-9, 27-10
lateral movement, configuring 26-32 routes for 39-10
terrain avoidance 26-31 writing plans for 35-19
rotary-wing-entity-param parameter 69-12, C-8
rotary-wing-entity-state-repository 69-12
rotating, ellipse 39-16 rotation path, smoothing 6-16 RotDir parameter 83-18
roughness type, mapped to soil type 19-17 round 10-2
route 37-2, 37-5 altitude
computed, creating 39-7 evaluating for aircraft 39-10 extruded 39-4
patrolling 27-23 using as road 27-13
revision 5-8, 5-13 specifying version B-7 version 5-8, 5-13
configuring for time management 4-18 definition of 2-8
RTI_CONFIG environment variable 2-9
rule, roll up 67-14 rules of engagement
Rules of Engagement dialog box 34-36 Rules of Engagement set data request 34-36 run
scenario, using PDU 7-41 run mode B-5
run-duration-time parameter 12-6 runInTimeManagementMode parameter 4-19, B-7 running 34-31
Boundary Generation Tool 57-16 simulation 7-24
-S command-line option 5-7, 5-8, 5-13, 5-20, 50-
-s command-line option 5-11, 5-15, 60-5 S-57
buoys and beacons 57-23 converting to shapefile 62-7 data 55-27
s57_layer_list.csv 57-23, 57-28
s57_modeldef_by_name_map.csv 57-26 Sail Heading dialog box 27-27
Sail Heading task 27-27 salvo 10-2
sample, scenario 7-23 sampling rate
intervisibility, configuring 46-9 San Luis Obispo terrain 53-20 Save Scenario dialog box 7-28 saved views file 6-1
scenario 12-2 saving
display engine configuration 77-5 element definition 81-32
global variables 33-14 hierarchy and leaves 81-36 model definition 81-20
object parameter database 70-12 plan 36-10
under new name 7-29 schemas 81-4
window layout 78-3, 78-6 scale
factor, material ambient and diffuse value 43-4 SpeedTree, random 83-24
Scaled Speed check box 49-29 scaling
scaling (continued)
model, linear and XR 19-23 scenario 6-1
checkpoints and snapshots 7-30 closing 7-27
collaborative development 7-12 component attachment table 7-6 compressed format 6-1, 12-2
specifying which to use B-4 format, saving to different 7-29 frame mode 7-7
order of battle 12-10 parameter
random number seed 7-7 remoteAttachment 76-2
rolling back to snapshot or checkpoint 7-25 running 7-24
under new name 7-29 simulation model set 7-6
scenario (continued) SMS, multiple 7-8
starting date and time 7-11 default 7-12
startup observer view 49-32 temporary directory 12-11
zoom to extents on load 49-22 scenario event 8-2
adding audio, video, and graphics 8-5 creating 8-3
sending from plan 8-11 Scenario Event condition 35-13 Scenario Event dialog box 8-11
Scenario Event Manager 8-3, 8-8, 8-10, 8-12, 8-13 Scenario Event Settings page 8-14
Scenario Event Toolbar 8-2 scenario extras file 12-2, 20-9
Scenario Information dialog box 7-23 Scenario Name parameter 7-5 scenario script 32-3
Scenario Snapshots dialog box 7-26, 7-31, 7-33, 7-
Scenario Startup dialog box 4-6, 4-7
ScenarioDescription parameter 12-6
ScenarioExtentInformation parameter 12-6
Scenario-Extras parameter 12-5 scenarioFileName parameter B-4 scenario-filename parameter 7-38
Scenario-Scripts parameter 12-5 scenario-specific
GUI settings file 12-2 spawn pattern 20-9
scheduling
schema (continued) creating 81-5
model definition 81-4 parameter
tactical graphic model 65-56 visual definition 81-4
Schema Editor page 81-5, 81-6, 81-7, 81-8, 81-12
Screen Number attribute 77-6 script
adding to task toolbar 32-23 availability, by simulation object type or
making available by Behavior Set 32-21 metadata 32-5
parameter types 32-13 previewing dialog box 32-10 saving 32-30
script ID 32-8, 32-11 set data request 32-3
simulation object type supported 32-20 system and scenario 32-3
Task menu location 32-17 Script Options page 32-37 scripted
actioncategory 26-36 adding to folder 32-32 adding to toolbar 79-6 background process 33-30
scripted task (continued) exporting and importing 32-32 filtering list 32-31
folder
in system definition 32-21 interactive 33-23
reactive task 26-12, 33-8, 33-29 removing from folder 32-32 rewinding 32-30
script storage location 32-32 system
making available on Task menu 32-35 storage location 32-35
scriptstext editor, specifying 32-37 sea
enabling and disabling 44-4 state 11-5, 11-18
swell 11-5, 11-18 sea spray, size 44-5
search, radar mode 34-33 search and rescue 28-20, 30-15
seasonal buoys and beacons 57-30 secondary
simulation object 50-10, 50-13
sector of responsibility, setting 34-37 Sector of Responsibility dialog box 34-37
Sector of Responsibility set data request 34-37 Sector Search Operation dialog box 28-20, 30-15 Sector Search Operation task 28-20, 30-15 segment
Selected Simulation Engine Toolbar 16-6, 16-8 selecting
entity, from Object Console Summary Panel 17-6
in Objects List Panel 17-6 multiple list box 26-8
adding object to new 17-9 adding to 17-10
creating from keyboard 17-9 creating from menu 17-9 deleting 17-10
removing object from 17-10 renaming 17-10
Selection Group View 17-2 SelectionGroups parameter 12-5 self, as condition parameter 36-22 self reflection, DIS 5-13
send buffer size 5-9, 5-13, B-8
Send NBC Report dialog box 31-29 Send Obstacle Report dialog box 31-30 Send Radio Set task 30-7
Send Radio Task task 30-9 Send Text Message task 30-10
sendBackendLogToNetwork parameter B-4
sendBufferSize parameter B-8 sendFedTime parameter B-7 sending
console message 36-33 data, configuring B-3 messages 15-9
sending (continued) radio messages 74-4
set data request via radio message 30-7 task via radio message 30-9
send-spot-reports-on-own-force parameter 9-7
sensing, electronic emission 23-16 sensing target 72-6
sensor 9-13, 15-8, 15-9, 71-2, 72-6
See also. sensor signature adding new 71-9
affect of posture 23-5 aiming 34-38
attaching to remote entity 76-2 channel attribute 77-7
information 18-4 mode, full color 45-5
sensor contact line 42-13 SIGINT 23-18
system definition file 69-17 editing 71-4
Sensor Aim set data request 34-38 sensor component, adding 71-11 sensor contact line
specifying objects that can display 42-14 sensor contact line pinning 42-14
sensor effects 45-2, 45-3 blur, noise, and gain 45-4 configuring 45-4
Sensor Enabled set data request 34-38 Sensor Settings page 45-4, 45-5
sensor signature 9-17, 65-29, 71-5
affect of posture 23-5 modifying 39-9
Sensor Zoomset data request 34-39
separation-distance parameter 26-11
separation-tolerance parameter 26-11
separator, menu 79-2 server
caching 61-3 cutting in site 57-14
assigning 4-8 configuring B-4 setting at startup 5-10
joining at startup 4-16 message, configuring 4-16 starting and stopping 7-41
Session Options page 4-7, 7-10, 7-11, 7-12, 7-22,
7-41, 18-18, 18-19, 49-22, 78-10
sessionId parameter B-4 set
Set command, default 34-4 set data request 25-2
Active Sonar Mode 34-5 Aiming 34-7
Allow Crossing set 40-4 Altitude 26-25, 34-8
Ammunition Pacing/Tracking 34-9
Collision Avoidance Types 34-12 Color 40-4
Counter Measures Auto Launch 9-19, 34-13
set data request (continued)
DI-Guy Characteristics 34-16 DI-Guy Hand Item 34-16 Disembarked 19-11, 34-17
Equipment Pacing/Tracking 34-20
Food, Water, Fuel, Oil, and Lubricant Pacing/Tracking 34-21
Food, Water, Motor-Gas, Aviation-Fuel, Diesel Fuel, Oil, Lubricant 34-20
Resources Pacing/Tracking 34-34
Resupply Mode 34-35 Rules of Engagement 34-36 script 32-3
Sector of Responsibility 34-37 sending by radio 30-7
Sensor Aim 34-38 Sensor Enabled set 34-38 Sensor Zoom 34-39
Synchronize Laser Code 9-16, 34-43
set data request (continued) tactical graphics 40-2
Tasked by Superior 26-12, 34-44
Weapons Pacing/Tracking 34-45 Set menu, icon 32-11
Set MOPP Level 34-27 Set Morale 34-27
Set Scenario End Time dialog box 7-35 Set Sensor Signatures dialog box 8-9 set statement 25-2
See also. set data request Set toolbar, adding to 79-6
setCheckpointMode function 33-14
setDeadReckoningAlgorithmToStaticOnPause
parameter B-5 setMainThreadToHighPriority parameter B-5 setting
altitude for fixed-wing entity 26-25 ambient air temperature 11-5, 11-10
collision avoidance types 34-12 color, unit bounding volume 25-11
combat engineering object percent complete 34-29
emitter volume radius 84-3 factory and default 4-21 formation 34-22
setting (continued) morale 34-27
notification level 5-16, 34-28
posture 34-31 precipitation
rules of engagement 34-36 saving 4-21
sector of responsibility 34-37 segment arc size 84-5 simulation object 34-4
simulation speed with time management 7-24 sound volume 47-3
target 34-43 time of day 11-4 time zone 11-4
weather 11-8 settings
Simulation Object Editor, GUI layout 64-5 synchronizing 4-23
debugging 61-8 shadow
enabling and disabling 43-19 text, 2D label 18-16
Shadow Settings page 43-20, 43-21
shaking camera 49-27 shape terrain data 52-3
shapefile
buoys and beacons 57-23 converting S-57 to 62-7 exporting overlays to 38-6 importing to overlay 38-7 layer name 57-9
mapping to feature 55-11 sharing, resources 6-11
sheaf radius 31-27 ship
shooter-and-impact-point range 72-20
Show Database Correlation Warning Dialogs 4-17 Show Function Profiler Overlay 6-8
Show Only Active Environmentals 39-19
Show Performance Statistics Overlay check box 6- 7
Show Session Terrain Change Prompts 4-17 Show Spot Reports from Viewpoint of Force 9-5,
Show Spot Reports Sent By 9-6 showHuds 77-7
showing
SIGINT sensor 23-18 signal
signal group attribute 57-31 signal period attribute 57-31 signal_slot 69-24
signature propagator, configuring 71-9 signature-object-sensor 71-2
license 1-19 simMgmtPduProcessLevel parameter B-5 SimObject class 33-4
simulated world, navigating 49-3 simulation
speed, with time management 7-24 start mode B-5
checkpointing in 7-32 evaluating in plan 35-13
Simulation Connections Configuration dialog box 4-32
Simulation Control Toolbar 4-11, 7-24, 7-25, 7-
Simulation Date/Time condition 35-14 simulation engine
simulation management message, configuring B-5 simulation model set 64-5
entity-level and aggregate-level 15-11 file 64-5
specifying on command-line 5-11 simulation model set configuration, default 7-9 Simulation Model Sets parameter 7-6 simulation object
adding to, selection group 17-10 assigning plan to multiple 36-39
simulation object (continued) attaching observer to 50-7 attaching tactical graphic to 39-11 attribute, information 18-4
automatically attaching tactical graphic to 39- 11
centering observer on 49-26 changing
collision and obstacle avoidance 19-16 communication model 15-7
console, setting notification level 34-28 console message 18-31
creating 16-3, 16-4, 16-8, 16-11, 19-3
creation, enabling and disabling 65-7 deleting 19-5
in plan 36-34 deleting in plan 36-33 destroyed 34-14
to new location 34-26 editing 19-5, 64-3
enumeration, published and matching 69-6 filtering attachment list 50-5
filtering using interest management 6-8 firing at target 9-13
CID level and color 9-13 image 83-9
simulation object (continued) information 18-3
extended 18-17 list, spot report 9-9 local and remote 3-9 model 64-5
reloading 65-27 move to location 27-16 name 18-9, 65-7
pinning intervisibility object to 46-10 placing 16-11
plan
properties, specifying at creation 16-13 random creation of 16-25
remote
removing, from unit 24-8 resource, monitoring 18-29 resource at creation 19-4 restoring health and stores 34-35 selecting 17-4, 17-5
from Object Console Summary Panel 17-6 in Objects List Panel 17-6
setting
state and parameters 34-4 specifying resource 34-34
spot report, enabling or disabling 34-41 state 15-9, 34-4
systems
tasking by superior 34-44 tick rate, tuning 6-13 track history 42-5
simulation object (continued) trailing effect 42-3
viewing in Navigation Lab 58-13 views of 17-2
ways to add to scenario 7-16 writing plan 36-3
zooming to extents 49-22 Simulation Object Editor 1-18, 64-3
configuring DI-Guy character and appearance 65-16
embedded entity 19-13 force
formation, bounding box 66-11 generating navigation data for entity 58-9 managing forces 64-22
navigating edited simulation objects 65-46 opening OPD Editor from 65-31 simulation object group 65-45
starting 19-19, 64-4 variable binding
system definition file 69-25 simulation object group 7-16, 16-25
Simulation Object parameter 32-16 simulation object type
Simulation Object Type Mappings dialog box 82- 2
filtering element definition list 82-7 Simulation Object variable 35-15 Simulation Objects Palette 16-3, 16-4, 16-5
assigning or removing simulation object 65-7 Simulation Ocean Settings page 55-27 Simulation Selection Toolbar 4-11
Simulation Terrain parameter 7-5 Simulation Time condition 35-13 Simulation Time Scale Toolbar 4-11, 7-24
range, changing 7-25 Simulation Time Toolbar 4-11
simulationModelSet parameter B-5
Simulation-Model-Set-Files parameter 12-6
simulation-run-duration parameter 7-38
SISO Enumerations Document 3-8
SISO Reference for Enumerations for Simulation Interoperability 69-4
site ID 3-4, 5-8, 5-9, 5-11, 12-9
configuring B-5 specifying 5-11
at startup 5-15 siteId parameter B-5 sitting 34-31
situational awareness 48-10 size
Size group box 65-10, 65-12 Skip Task, task 26-12 skipping task 26-10
skybox cube map 43-14 omitting clouds 43-14
Skybox Cube Map Regeneration Threshold 43-14 slider
visual quality, configuring 6-16 slot
smallCompass, keyword 49-5 smoke
smoothing 6-16 SMS
snap to grid, formation 66-14 snapshot 7-30
enabling periodic 7-34 rolling back to 7-25 saving as checkpoint 7-31
SOEUILayoutSettings 64-5 SOG. See simulation object group soil type 61-13
configuring for GDB 53-2 mapped to roughness type 19-17 point and feature 53-16
solid line 39-17 sonar
active, mode 34-5 active and passive 9-17 depth 34-40
thermocline 9-17, 11-22 Sonar Depth dialog box 34-40
Sonar Depth set data request 34-40 Sonar Dip task 30-18
mapping, weapon fire and detonation 47-8 mapping to entities 47-4
sound file, mapping to entity 47-5 sound mapping
detonation result 47-8 Space Follow mode 50-11 spacing, contour line 53-10 spawn burst 20-8
spawn event, scheduling 20-6 spawn interval 20-6, 20-8, 20-12
spawn pattern (continued) copying 20-14
Spawn Pattern Manager 20-2, 20-4, 20-10, 20-14,
spawned, entity 20-2 specifying
default default.sms 64-18
default SMS 64-18 entity to create 21-8 FED file 5-19
frame length 12-6 frame rate mode 12-6
HLA federation execution 5-17 language 5-4
point-to-point and multicast modes 5-20 port, at startup 5-20
segment angle 84-5 simulation model set 5-11 site ID 5-11
terrain profile sampling frequency 54-3 unit target 34-32
specular
enabling and disabling 49-29 setting 34-29
specifying measurement unit 78-11
speed (continued)
speed-to-rpm-factor parameter 9-18
SpeedTree Randomization page 83-25 SpeedTree Settings page 83-23 speedTreeManager 57-7 spheroidSemiMajor parameter B-5 spheroidSemiMinor parameter B-5
spot report 5-4, 9-2, 31-29, 31-30 affect on performance 6-12 custom viewpoint 9-6
for simulation object 34-41 icon
role in target detection 9-15 tactical graphics, for 9-9 using in task 9-9
Spot Report Options page 9-3, 9-5, 9-6, 9-8, 9-9,
Spot Reports dialog box 34-41 Spot Reports set data request 34-41 spotlight 43-2, 43-6
spray, enabling and disabling 44-6 squatting 34-31
enabling and disabling 42-21 lifetime 42-22
standard-power-type parameter 72-28
standard-terrain-damage-table 72-29
standard-terrain-damage-table block 72-28
standard-terrain-damage-type parameter 72-28
starting
Simulation Object Editor 19-19, 64-4
VR-Forces 4-3 startInRunMode parameter B-5 startMinimized parameter B-5 Start/Resume message 7-41 startup
back-end minimize B-5 option 5-1
tutorial 4-9 state
simulation object, information 18-4 update, sending 48-11
state repository 72-7, C-4 hierarchy 69-10, 69-12
statement
adding to plan 36-4 deleting 36-10 editing in plan 36-9
state-repository parameter C-4, C-6
state-repository-min-tick-period parameter 6-14
state-repository-min-tick-period-variance parameter 6-
statistics
frame rate, log file B-3 status
combat engineering object 23-12 entity 18-29
personnel, ammunition, weapons, and POL 18- 7
statusUpdateHeartbeat parameter B-5 Stealth
stereo display, types of 77-20
Stop/Freeze message 7-41 stopping
stopping-distance-factor parameter 73-4 stores, restoring simulation object 34-35 Stow Refueling Boom task 30-13
Strafe Ground Target dialog box 28-22 Strafe Ground Target task 28-21 strafing, target 28-7
streamed data performance 6-12
processing 57-7 streaming
buoys and beacons 57-23 navigation lights 57-29
strength 23-3 strong point
improving 31-26 style
subgoal 3-15 submarine
lowering periscope 30-12 moving to depth 27-15 raising periscope 30-13
subnet mask 5-9, B-8 subnetMask parameter B-8 subordinate
adding to unit 66-5 disaggregated state 24-9
order, changing 66-6 removing from unit 66-5 replacing 66-6
unit, aggregated state 24-9 Subordinates tab, unit 24-9 substitute-message-size parameter 13-3
subsurface entity
moving to depth 27-15 RPM 9-18
subsurface-entity-param parameter 69-12
subsurface-entity-param parameter C-8 subsurface-entity-state-repository 69-12 subtask
state
sunset-time parameter 71-13 superior
tasking simulation object 34-44 Superior dialog box 34-42 Superior set data request 34-42 super-type 69-5
starting or stopping delivery 34-42 Supplies page 23-12
supplies parameter, editing 67-24 supply line 42-17
Supplying dialog box 34-42 Supplying set data request 34-42 support, technical lvi
suppression-degrades-sensor-performance-by parameter 26-35
suppression-detonation-insult parameter 26-34
suppression-detonation-range parameter 26-34
suppression-insult-level parameter 26-34
suppression-recovery-time parameter 26-34 suppressive fire
at point, line, or area 26-32, 28-17 suppressSelfReflect parameter B-8 surface
damage specification 72-22, 72-26
surface (continued)
transparency 11-16, 11-18, 77-16 type, mapped to roughness type 19-17
surface-entity-param parameter 69-12, C-8 surface-entity-state-repository 69-12
surge depth 11-5, 11-16, 11-18 surrender
surrendered 35-12 Surrendered dialog box 34-42
Surrendered set data request 34-42 swell 1-14, 11-5, 11-16
visual model 65-25 Switch Node States 65-25
SwitchStateMapper, feature 83-20 symbol, location of 2-4
symbol decoration, showing and hiding 18-15 Symbol Decoration Settings page 18-14, 18-15,
synchronization, vertical 6-19 Synchronize Laser Code dialog box 34-43
Synchronize Laser Code set data request 9-16, 34- 43
synchronized, ocean 5-6 synchronizing
data and settings 4-23 laser codes 34-43
sysdef file. See system definition file system 69-17
adding to simulation object 65-30 aggregate-comms-jammer 23-16
system (continued) explosive device 72-16
marker in 3D model view 65-31 missile launcher 72-11
Naval Depth Charge Deployment 28-4 Naval Mine Deployment 28-5, 28-6 naval mine explosive device 72-16 removing 65-32
scripted task, creating 32-35 sensor 71-2
simulation object, editing 65-28 weapon 72-3
system definition, specifying scripted task in 32-21 system definition file 69-17, 72-3
applying new variable bindings 64-19 configuring connections 69-18
addingto Simulation Object Editor 69-25 system scripted task, making available on Task
-t command-line option 60-5 tab
overlay 38-4 table
active and inactive 39-19, 40-3 attaching to simulation object 39-11
automatically attaching to simulation object 39- 11
changing state with set data requests 40-2 color, changing 39-16
compared to combat engineering object 23-11 console, notification level 18-32
tactical graphic (continued)
creating 16-3, 16-4, 16-5, 16-8, 16-9, 16-11,
element definition 81-21 export to shapefile 38-6 extruded 39-4
hiding from Overlays tab 37-8 importing shapefile to 38-7 information 18-3
moving, to different overlay 39-5 notify level 40-5
placing 16-11 property
setting at creation 16-13 publishing 39-7
showing and hiding 37-6, 37-8, 39-19, 40-3
texture 65-56 vertex
Tactical Graphic Active condition 35-14, 39-19,
Tactical Graphics Display Settings page 37-8, 37- 9, 37-10, 39-17, 41-3
Tactical Graphics Palette 16-4, 16-5 Tactical Graphics Settings page 39-19 tactical smoke, enabling or disabling 42-17 taillight 43-2, 43-6
takeoff, fixed-wing entity 26-26, 26-28
taking off 27-8 target
target (continued) firing at 9-13, 28-9
identifying with laser beam 9-15 setting 34-43
specifying using laser 28-12 strafe 28-7
unit, preferred 34-32 Target dialog box 34-43
target selection controller 72-6, 72-11, 72-13 Target set data request 34-43
targeting-capable parameter 34-18
targeting-control parameter 72-6
Activate Jammer 31-4 adding to plan 36-4
Animated Movement 27-3 Anti-ship (Fixed Depth) 28-14 Arm Mine at Depth 28-3 articulated parts, moving 30-11 assigning to unit 26-11
Attack Aircraft with Guns 28-3 Attack By Fire 31-5
Attack with Anti-Air Missile 31-5 Attack with Anti-Ship Missile 31-5 Attack with Land-Attack Missile 31-6 Attack with Torpedo 31-6
Automatic Air Defense 31-6 background 31-31
Change MOPP Level 31-10, 34-27
Close Cargo Door 30-11 Close Door 29-2
Close Window 29-2 Come to Stop 27-4 concepts 25-1
concurrent 25-1, 26-5, 32-8, 32-18 configuring mutually exclusive 26-35
task (continued)
confirmation prompt, enabling or disabling 26- 6
Construct Anti-Tank Ditch 31-13 Construct Barbed Wire 31-14 Construct Barricade 31-14
Construct Berm 31-15 Construct Booby Trap 31-15 Construct Bridge 31-16 Construct Dry Gap 31-17 Construct Fortified Area 31-18 Construct Fortified Line 31-19 Construct Minefield 31-20 Construct Strong Point 31-21 Convoy Along 26-11, 27-4
Create Pedestrians 29-3 Crowd Along Line 29-3 Crowd Around Location 29-4 Crowd Around Object 29-4 Crowd in Front of Entity 29-5 Deactivate Jammer 31-21 Deploy Refueling Boom 30-12 Deploy Sonobuoy 30-17
Deploy Sonobuoys Along Route 30-17 Destroy Bridge 31-22
Drop Naval Depth Charge at Location 28-4 Drop Naval Mine 28-5
Drop Naval Mines Along Route 28-6 Embark 19-8, 30-4
escaping retask procedure 26-7 Execute Close Air Support 28-7 Explode Charge at Depth 28-9 FASCAM 31-24
filtering simulation object list 26-10 Fire at Target 28-9
Fire Cruise Missile 28-10 Fire-for-Effect 28-11
task (continued)
Fixed Wing Takeoff 26-28, 27-8 Flee From Entities 29-6
Fly Heading and Altitude 27-10 Follow Entity 27-11
Generate Air Traffic From Flight Plans 27-12 Halt Movement 31-24
Improve Booby Trap 31-24 Improve Breach 31-25
Land at Airport Near Location 27-12 Lase Target 9-16, 28-12
Launch Anti-Submarine Missile (Vertical) 28- 12
Launch Counter Measures 9-19 Launch Smoke 28-13
parameter 33-17 Move Along Route 27-13
Move Along Route Retrograde 31-28 Move Into Formation 27-14
Move to Altitude 27-15 Move to Depth 27-15 Move to Location 27-16
Move to Location (Plan Along Roads) 26-22, 27-18
Move to Location Retrograde 31-28 Move to Waypoint 27-20
Move to Waypoint (Plan Along Roads) 26-22, 27-21
Move to Waypoint Retrograde 31-28 movement, affect of aggregation state change
mutually exclusive 25-1, 26-5, 35-7
Nuclear Attack 31-29 Open Cargo Door 30-13 Open Door 29-6
task (continued)
Pattern Hold (Location) 27-24 Pattern Hold (Waypoint) 27-25 performing 15-9
procedures, introduction 26-3 Protest Along Line 29-7 Protest Around Location 29-7
Provide Suppressive Fire 26-32, 28-17 Provide Suppressive Fire on Location 26-32,
reactive 21-10, 26-12, 30-19, 32-5, 33-8, 33-29
Release Bomb on Laser Spot 28-18 Release Bomb on Location 28-19 Release Bomb on Target 28-19 retask 26-3
Rotary Wing Airlift Cargo to Location 27-25 Rotary Wing Land 27-26
Rotary Wing Retrieve Cargo 27-26 Rotary Wing Unload Cargo 27-27 Sail Heading 27-27
action category 26-36 adding to task toolbar 32-23 adding to toolbar 79-6
available by Behavior Set 32-21 execution flow 33-9
Sector Search Operation 28-20, 30-15 Send Radio Set 30-7
Send Radio Task 30-9 Send Text Message 30-10 simulation object 15-10
spot report, using in 9-9 state
Stow Refueling Boom 30-13 Strafe Ground Target 28-21
Throw Grenade at Location 28-23, 28-24 toolbar, adding to 79-6
task (continued)
Turn to Heading 27-28 unit concepts 22-5
Wander 29-7 Wander In Area 29-8 who can execute 26-7
system scripted task, hiding 32-35 task visualization B-6
Tasked by Superior set data request 26-12, 34-44 using in plans 35-18
task-manager parameter C-5, C-7 taskParameters, table 33-17 taskVisualizationPublicationMode parameter B-6 TDB Tool 51-1
tearing off menu 78-8 technical support lvi teleporting observer 49-16
temperature, air 11-5, 11-10 template
temporary directory, scenario 12-11 terminating, application 4-24 terrain
See also terrain database and terrain server
agility 1-12, 52-2 altitude point
caching earth files 1-18 coloring by elevation 53-4 composability 52-2
terrain (continued)
deleting cached 61-6 displaying raster image on 55-7 dragging with mouse 49-14 DTED support 55-4
global dynamic terrain processor 7-7 earth file, debuggin 61-14
extracting props from 52-4 feature data, configuring 62-2 file caching 61-2
formats, supported 52-3 GDB, soil type 53-2 geocentric 52-6
loading, from command line 5-7 Makland 53-19
orbiting, with mouse 49-15, 49-18 paged
flipping DDS textures 61-11 loading 5-10
adding to terrain 55-5 extracting props from 55-20
placement of new entities 19-3 profile. See terrain profile prop
San Luis Obispo 53-20 saving 55-4
terrain (continued) scale 53-17
server. See terrain server shape 52-3
simulation object group 5-5 soil type 53-16
Terrain Contents page 55-6, 55-12, 55-15, 55-16,
terrain damage, standard 72-28 terrain database 1-12, 52-6
changing for a scenario 12-8 configuring B-6
at startup 5-12 terrain draw area 53-18
Terrain Information Panel 53-14 terrain profile
displaying, line creation 39-6 line 37-2, 54-6
sampling frequency 54-3 terrain profile line 54-6 track history 42-7
Terrain Profile Settings page 46-12 Terrain Profile window 54-2, 54-3
terrain server 52-7, 52-9, 56-2
connecting through proxy 56-5 cutting in site 57-14
mask, adding 57-14 Terrain Settings dialog box
Add Props page 55-22, 63-9, 63-13 Earth Layers page 53-12
Edit Existing Props page 55-24, 55-25, 55-26,
Extract Ocean page 55-15 Extract Props page 55-20, 63-21 Navigation Areas page 58-3
Raster Maps page 55-7, 55-10, 63-5 Simulation Ocean Settings page 55-27
Terrain Settings dialog box (continued) SpeedTree Randomization page 83-25
Terrain Contents page 55-6, 55-12, 55-15, 55-
Terrain-Database parameter 12-5
terrain-following, fixed-wing entity 26-26 TerraPage file 52-3
testing, amount of resources 35-13 Tether Location Track mode 50-13 Tether mode 49-8, 49-26, 50-7, 50-12
Tether Track mode 50-13 text
in title bar 78-10 object, resizing 39-15
atlas, buoy and beacon 57-27 compression, enabling and disabling 61-6 coordinate system for image 55-9
height, ocean planar reflection 43-10 map 1-15, 61-7
mapping to model 83-19 model 83-19
size, ocean height map 55-17, 55-18 skinning
tactical graphic 65-56 tiled and virtual 60-4 water 55-13
width, ocean planar reflection 43-10 texture atlas 83-19
thermocline, sonar 9-17, 11-22 thickness, contour line 53-10 this, Lua object 33-4
threat ring 18-24 threshold
threshold (continued) DIS heartbeat B-7 object timeout B-7
Throw Grenade at Location dialog box 28-23 Throw Grenade at Location task 28-23, 28-24 Throw Grenade at Target dialog box 28-24 tick
rate, tuning 6-13 tidal current
speed and direction 11-16 tidal stream, wake 11-19, 83-17
tiled texture 60-4 time
evaluating in plan 35-13 scenario
setting in new scenario 7-7 simulation 3-10, 7-11
time constrained 4-17 time management
RTI requirements 4-18 setting simulation speed 7-24
Time Multiplier parameter 7-6 Time Multiplier toolbar 12-5 time of day 3-10, 11-2
time stamp order, configuring B-7 time stamp ordered message 4-18 time zone 11-2
time-multiplier parameter 12-5 timeout
timing, spawn pattern 20-11 tire track 42-3
title bar
text, adding 78-10 To Echelon Level 25-7 toolbar
adding task or set 79-6 Attachments 50-2
Display Settings 18-15 displaying and hiding 78-3 element 79-6
Environment Settings 11-3, 11-4
Objects 17-6, 19-7, 19-10, 24-6, 25-4
Simulation Control 7-24, 7-25, 7-26 Simulation Objects Palette 16-5 Simulation Time Scale 7-24
task, adding script 32-23 toolbarrow, element 79-6 topmark, buoy and beacon 57-31 topmark_attr_map.csv 57-31
Tracer Use dialog box 34-44 Tracer Use set data request 34-44 tracer-type parameter 72-8
track, radar mode 34-33 track history
enabling and disabling for all simulation objects 42-5
Track History Settings page 42-7 Track mode 49-8, 50-7, 50-14 tracking
tracking (continued) entity, resources 18-29
tracking beam 34-18 traffic
trailing effects 42-3, 82-2 enabling and disabling 42-4 model 42-4
trajectory, smoothing 6-16 trajectory history. See track history transform, multiple 62-5
transforming, attribute 62-4 transient intervisibility
object 46-5 transition time
posture, editing 67-21 translating, GUI text 2-10 translation 67-26
transmitter, publishing radio 74-4 transparency 83-26
surface 11-5, 11-16, 11-18, 77-16
tread track 42-3 tree
SpeedTree 83-22 triangle, vertex label 37-9 triangle icon 18-35
cleaning up unused 36-9 deciding order in plan 35-17 name 35-8
unregister 36-9 Triton Ocean SDK 1-20
tuning
network performance 6-15 performance
Turn to Heading dialog box 27-28 Turn to Heading task 27-28 turret, attaching to 50-4
tutorial
TXP file 52-3 type
-u command-line option 60-5 UI file 69-23
variable binding, adding 69-24 unconstrained 4-17
underFireDistance parameter 34-36
underwater, visibility 11-16, 11-18 Underwater Acoustics PDU 9-17 undo, ellipse rotation 39-16 undocking, panel 78-2
undoing
simulation object edits in Simulation Object Editor 65-8
unexploded ordnance, destroying 31-22 unique
adding simulation object to 34-42 aggregated state 24-9
unit (continued)
ammunition, weapons, equipment 67-5, 67-8
from combat engineering object 23-10 bounding box, Simulation Object Editor 66-11 bounding volume, color 25-11
changing state manually 24-12 closing formation 22-5
collapsing 25-3 collapsing to root 25-3 convoy 27-4, 27-5
disaggregated and aggregated 22-2 disaggregated state 24-9
display 78-11 displaying by level 25-4
displaying ghosted icons 25-6 echelon ID 22-3
entity, individual tasks and plans 24-11 entity-level 22-2
expanded and collapsed 22-2 expanding 25-3
expanding and collapsing 25-2 footprint 23-4
renaming 66-10 snap to grid 66-14
affected by combat engineering objects 23-9
unit (continued)
moving to formation 27-14 new 67-3
removing simulation object from 24-8, 34-42
reorganizing 22-4, 22-5, 34-33
setting formation in plan 35-18 specifying as Aggregate As option 66-3 state
affect on movement task 24-10 affect on resource tracking 24-10 at creation 24-6
changing at runtime 24-10 initiating change 24-11
setting 34-44 showing in GUI 24-9
Unit Display Settings page 25-7, 25-10, 25-11,
Unit State dialog box 34-44 Unit State set data request 34-44
Universal Transverse Mercator 52-6 unloading
entities from entities 19-7 unlocking, overlay 38-3 unpublishing, tactical graphics 39-7 unregistering, trigger 36-9 unselecting
unused range 72-20 update
frequency of B-3 messages 48-11
Update_EW_Degradation, script 23-17
updating
window layout 78-6 upgrades lvi upgrading, SMS 64-14
Use Extracted Geometry 55-20 useAbsoluteTimeStamps parameter B-7, B-8 use-actual-message-size parameter 13-3 useAdvisories parameter B-7
useAsyncIO parameter B-8 useCustomMapDatum parameter B-6 Used By Countries list 65-9
useDIGuy parameter B-6 useDrawControlForTaskVisualizations parameter B-6 useIpv6 parameter B-8
use-logger-control parameter 7-38 user
user data, specifying directory 5-7 User Task dialog box 30-18
user-defined, formation 73-4 using
Boundary Generation Tool 57-15 navigation data 58-8
-v command-line option 5-7, 5-12, 5-14, 60-5
vapor trail 42-3 variable
adding to platform file or system definition file 69-22
adding to Simulation Object Editor 69-21 applying changes 64-19
Simulation Object Editor, adding new 69-23 variable frame mode 6-17
variable-frame run-to-complete 3-11, 12-6
variance, spawn interval 20-6, 20-8 varying, heartbeat B-7
vector
network 26-22 vector feature
configuring avoidance of 73-5 list 53-14
vehicle, model 1-7 velocity
specifying measurement unit 78-11
vel-to-align-actual parameter 26-32
vel-to-align-desired parameter 26-32 version
version (continued) plug-in, checking 5-3
version parameter, scenario file 12-6 vertex
line, terrain profile 54-3 showing and hiding 37-9 tactical graphic, color 39-17
video, adding to scenario event 8-5 video card, processor speed 6-4 view
dragging with mouse 49-15 floor 49-28
observer, transitioning between 49-32 recalling 49-30
saved, scenario 12-2 saved with scenario 6-1
view constraint, disabling 19-4 view control, sending in plan 36-35 view control message 49-34
enabling processing of message 49-34 script 49-34
Mimic Location Track 50-10 Mimic Track 50-10
Tether Location Track 50-13 Tether Track 50-13
viewing
current task 35-16 list of props 55-24 Logger files 7-41
obstructed terrain in terrain profile 46-12 other MAK 3D GUI viewers 48-12
terrain polygons 53-18 viewpoint
Virtual Texture Datasets 60-3 visibility 11-8, 11-10
visible surface, configuring 53-2 Visible Surfaces page 53-3
Visit Interest Points reactive task 21-10 visual definition 81-4, 81-21, 81-25
Entity Image Symbol 83-2, 83-4, 83-9 Military Symbol Icon 83-2
schema 81-4 visual model
Visual Model Editors dialog box 81-9 visual quality 55-17
visual quality slider, configuring 6-16 visual sensor 71-12
visualization, task B-6 visualizer 81-21
visualizing, tasks 42-12 volume
volumetric, tactical graphic 39-4
vrf-base-object-param parameter 69-26, C-3 vrf-base-object-param parameter type C-7 vrfGui 3-2
vrfGui.log file 4-38 vrfLauncher
special command-line arguments 5-15 vrf-moving-object-state-repository 69-12
vrf-object-param parameter C-7
vrf-object-param parameter 69-12
vrf-object-state-repository 69-12 VR-Forces
entity or object 3-9 Launcher 4-3
VR-Forces Objects Panel 50-2 VR-Forces window 7-7
vrf-overlay-object-state-repository 69-12 vrfSim
daemon, starting as 5-10 vrfsim
layer 62-2 VRFSIM_OSGEARTH_CACHE_PATH
vrfSim.log file 4-38 vrfSim.mtl file B-2 vrfSim.opd
remote-configurations block 76-3 required in every SMS 64-9
VR-Vantage, view control 36-35 VR-Vantage Control Toolkit 49-34 VSync 5-4, 6-19
W
Wait Duration dialog box 30-11 Wait Duration task 30-11
Wait Elapsed dialog box 30-11 Wait Elapsed task 30-11
Wait Until Expression dialog box 36-6 wake 1-14, 1-20, 42-3
enabling and disabling 44-6 model definition 11-19
wall, not walking through 49-28 wall-clock time 4-18
wander, crowd 29-8 Wander In Area task 29-8 Wander task 29-7
warfare, electronic 23-16, 23-17, 23-18 warfare model, aggregate 23-2
warhead-detonation-actuator 72-16
warning, icon 18-35 warning message B-4 water
pacing and tracking 34-21 splash 44-2
visibility 77-16 water droplet, size 44-5 wave
altitude, displaying 37-10 civilian visit point 21-9 ordering entity to 27-20 patrolling between 27-24
weapon
fire, sound mapping 47-8 laser guided 28-12
pacing and tracking 34-45 status 18-7
weapon (continued) system 65-28, 65-29
system definition file 69-17 unit 67-5, 67-8
Weapons Pacing/Tracking dialog box 34-45 Weapons Pacing/Tracking set data request 34-45 weather 11-5
Weather page 11-6, 11-7, 11-8, 11-9, 11-10, 11-
While Expression dialog box 36-6 While statement 35-4, 35-9
width
changing for line 39-17 sensor contact line 42-15
moving flags and windsocks 83-18 offset 10-2
speed and direction 11-8, 11-9
WindDirPart 83-18 window
Add Visualizer Definition Attribute 81-30 adding 77-2
Multiple Object Information 18-9 new 4-13
window (continued) removing 77-5
selecting simulation objects in 17-5 size, changing 77-6
types 77-2 window layout
creating 78-4 default
Window Layout Manager dialog box 78-4 Window Name attribute 77-6
Window Type attribute 77-6 Windows, installing on 2-2 windsock, movement in wind 83-18 WindSpeed parameter 83-18
world coordinates 49-3 writing
global plan 36-26 plan
for multiple simulation objects 36-39 for unit 24-12
WRM Entity Model Specification 85-1, 85-9
-x command-line option 5-8, 5-9, 5-13, 5-17, 5-
RTI configuration file 2-9 XML file
yellow triangle icon 18-35 Z Far 77-7
Z-fighting 5-7, 50-6, 55-13, 77-10, 77-16
zone
weather 11-13 zoom
scale factor, LOD 49-20 scenario, on load 49-22 SpeedTree LOD 5-7
switching from 3D to 2D 48-2 to entity extents 49-22
to extents 49-22 zooming
VR-Forces Quick Reference Card
Table QR-1: vrfSim Command-Line Options
Option Description
Option Description
(-a | --appNumber) application_number Specifies the application number.
--additionalSystemScriptsDirectory directory Specifies a directory where VR-Forces will look for system scripts
when it populates the Scripted Task dialog box script list.
--appDataDir directory Specifies the location of the appData directory.
--appIdRange lower-upper Specifies a range of application IDs that represent objects generated by VR-Forces.
(-B | --batchScenarioFileName) batch_file Runs the specified batch file. (For use with one back-end only.)
(-c | --frontEndPID) PID The process ID for the front-end when running in combined mode.
--countryCodesMappingFile file_name Specifies an alternative file that maps country codes to country
names and DIS enumeration values.
(-d | --settingsFile) file_name Specifies a configuration file to load instead of vrfSimSettings.xml.
--daemon Starts that back-end as a daemon process (Linux only).
--dataDir directory Specifies the data directory for the back-end.
--diGuyAnimationsFile file_name Specifies an additional configuration file for DI-Guy animations.
--diGuyCharacterDataFile file_name Specifies an additional configuration file for DI-Guy character data.
--disableCallbackQueue Disables all main thread parallel algorithms.
--disableParallelTick Execute all tick code serially.
--doNotLoadVrfPlugins Do not load any VR-Forces plug-ins from the ./plugins directory.
--enableChannel channel Enables a specific channel for the channel-specific output, even if it is disabled in channelSettings.mtl.
--fileNotifyLevel level Notify level in log file to use.
--fullyLoadTerrain For paged terrains, load all pages.
(-h | --help) Displays help information in a console window.
--hostAddressString address The IP address of the host computer. (Device Address in Launcher.)
(-i | --sessionId) session_ID Specifies a session ID.
(-L | --scenarioFileName) Loads the specified scenario. Mutually exclusive with the -T option.
"scenario_pathname"
--loadPlugin plugin_file Specifies one or more plug-ins to load. (Accepted multiple times.)
--logFileName filename Log file to use.
--logFrameRateStatistics Specifies that the back-end should log frame rate statistics.
--msdlSIDCMappingFile file_name Specifies an alternative file for mapping SIDC codes to DIS enumera-
tions.
(-n | --notifyLevel) notification_level Sets the level for messages written to the console or the VR-Forces log file (vrf.log).
--noRtiCompilerCheck Disable RTI Compiler version check.
--nonVrfObjectsUUIDScheme scheme Sets the UUID scheme for non VR-Forces objects. Values are
entity-identifier, global-identifier, marking-text.
Table QR-1: vrfSim Command-Line Options
Option Description
Option Description
--numCallbackThreads threads Number of threads in the callback queue.
--outputLogFile file_name The file to use to write out application output.
(-q | --doNotUseConsole) Specifies that all vrfSim output go to the log file.
(-r | --startInRunMode) Starts the back-end in run mode.
(-s | --siteId) site_id Specifies the site ID.
--setMainThreadToHighPriority If enabled sets the VR-Forces main thread to high priority. Windows
only.
--simulationModelSet sms Specifies the simulation model set.
--startMinimized Minimizes the vrfSim console at startup.
(-T | --terrainDatabase) terrain_database Specifies a terrain database to load in the back-end. Mutually exclu-
sive with the -L option.
--targetFrameRate rate Specifies the frame rate above which vrfSim will yield CPU time.
--useAbsoluteTimeStamps Use absolute time stamps instead of relative time stamps.
--userDataDir directory Specifies the user data directory for the back-end.
--disableParallelPreprocess Disables parallel processing for components that use it.
(-v | --version) version Displays version information.
--waitQueue Turn off main thread participation in parallel algorithms.
(-- | --ignore_rest) Ignore all command-line options that are listed after this argument.
HLA Only
HLA Only
(-f | --fomMapperLib) libname FOM Mapper library name.
(-F | --fedFileName) fedfile_name FED file name.
--fomMapperInitData data FOM Mapper initialization data.
--fomModules module Specifies an HLA Evolved FOM module. Can be used multiple times.
--ignoreAdvisories Enables or disables HLA advisory messages. Default: true.
--mimModule Specifies an HLA Evolved MIM module.
(-N | --federateName) federate_name Specifies a unique name that can be assigned to the federate.
Default: VR-Forces. (HLA Evolved only)
(-p | --federateType) type Distinguish different categories of federates.
--rprFomRevision RPR FOM revision for RPR FOM 2.0, draft 17.
--rprFomVersion version_number RPR FOM version. (0.5, 0.7, 0.8, 1.0, 2.0006, 2.0014, 2.0017 or
2.0)
--localSettingsDesignator designator Specifies a string that is passed to the RTI during federate connect
when using HLA Evolved.
--timeManagement Enables time management for the back-end.
(-x | --execName) exec_name Execution name. Default: VR-Link.
DIS Only
DIS Only
(-A | --destAddrString) address Destination address.
--defaultObjectTimeout timeout Specifies the timeout interval for objects.
Table QR-1: vrfSim Command-Line Options
Option Description
Option Description
--deviceAddress address Specifies the address of the network card to use for UDP traffic.
--disVersion The DIS version. Default: 5.
--mcastTtl Specifies the multicast time-to-live. Default: -1.
(-S | --multicastAddresses) address1 ... Specifies one or more multicast addresses.
addressn
(-P | --disPort) port DIS port.
--recvBufferSize size Receive buffer size.
--sendBufferSize size Send buffer size. Default: -1.
--subnetMask mask Specifies the subnet mask.
--suppressSelfReflect Represses self reflection of the DIS exercise connection.
--useAsyncIO Use asynchronous I/O. Default: False.
--useIpv6 Specifies that the DIS exercise connection use IPV6.
(-x | --exerciseId) ID Exercise ID.
Table QR-2: vrfGui Command-Line Options
Option Description
Option Description
(-- | --ignore_rest) Ignore all command-line options after this one.
--alphaBits bits Sets the number of alpha bits (0, 8).
--antiAliasing level Set the anti-aliasing level (0, 2, 4, 8, or 16). Default: 4.
--appDataDir directory Specifies the location of application data.
--appIdRange range Application ID range of VR-Forces back-ends.
(-c | --showConsole) Display a console window.
(-C | --autoConnect) {filename | Automatically connect to the network using the specified connector.
connector_name}
--dataDir directory Specifies the location of the data directory .
--defaultSimulationModelSet sms The simulation model set to use as the default when starting up the GUI.
--depthBits bits Sets the depth of graphics to 24 bits or 32 bits. Default: 24.
--dis Use the DIS protocol and enable DIS-specific options.
--disableDynamicTerrain Disables the dynamic terrain engine.
--discoveredModelPreloadFileName
filename
Specifies a file to which the list of models discovered during a session that were not preloaded is written.
--dispSetting filename Specifies the display configuration to load.
--doNotCheckPluginVersions Do not check the version in a plug-in to make sure it can load in VR-
Forces.
--doNotLoadVrfPlugins Prevents loading of plug-ins in the ./plugins directory.
--enableVSync Turns on VSync.
--entDispSetting filename Specifies the entity display setting to load.
--entityDefsDir directory Loads the .hier and .leaf files in the specified directory.
--envSetting filename Specifies the environment configuration file to load.
(-E | --entTypeMap) filename Load the specified entity type mapping file. The file extension determines
the type of mapping.
--factoryRootDir Set the root directory used to restore settings to factory defaults.
--fileTransporterReceivePort port Port for the file transporter.
--forceTextShaping Force all text to use HarfBuzz shaping.
--fowPerspective force Shows the ground truth and spot reports perspective for the specified
force.
--fullScreen Start in full screen mode.
--frameRate rate Specifies a fixed frame rate for rendering. If 0, it is variable.
(-G | --locale) language Specifies the locale (for localization).
--gui filename Specify GUI configuration file to load.
(-h | --help) Displays command-line usage information.
--highestPriority Changes application and the main render thread to the highest available priority.
--hla13 Use HLA 1.3 and enable HLA-specific options.
--hla1516 Use HLA 1516 protocol and enable HLA-specific options.
--hla1516e Use HLA Evolved protocol and enable HLA-specific options.
(-I | --unbatchedRendering) Disables instance rendering.
(-K | --disableKDTrees) Disable creation of KD trees for intersections.
(-l | --logFileName) filename Specifies the log file name.
--layoutSettingsFile filename Specifies the GUI layout settings file to use. filename specifies the base
filename. It is prefixed with default_ and the extension .uisx is added.
--loadPlugin filename Specifies plug-ins to load. Accepted multiple times.
--loadSimulationObjectGroup group Creates a new scenario on the simulation object group editing terrain and
creates an instance of the simulation object group on that terrain.
(-L | --loadObservers) filename Loads the saved observers in the specified file. Can be used multiple
times.
--mainScreenNum num Specifies the display that the main window should use.
--mergeEntityTypeMap {directory |
filename}
Merges all entity type mapping files (*.metx) in a directory or individual entity type mapping files. Can be used multiple times.
--mergeHierarchyEntityDef filename Merges the specified .hier file into the default hierarchy. Merging is addi-
tive.
--mergeHierarchyTacticalGraphicsDef
filename
Merges the specified .hier file into the default hierarchy. Merging is addi- tive.
--mergeHierarchyUnitDef filename Merges the specified .hier file into the default hierarchy. Merging is addi-
tive.
--mergeLeafEntityDef filename Merges the specified leaf file into the default entity element definitions.
--mergeLeafTacticalGraphicsDef
filename
Merges the specified leaf file into the default tactical graphics element definitions.
--mergeLeafUnitDef filename Merges the specified leaf file into the default unit element definitions.
--mergeModelDefs {directory |
filename}
Merges all model definition files (*.ommx) in the specified directory or individual model definition files. Can be used multiple times.
Table QR-2: vrfGui Command-Line Options
Option Description
Option Description
--mergeTacticalGraphicsTypeMap
{directory | filename}
--mergeUnitTypeMap {directory |
filename}
Merges all tactical graphics type mapping files (*.metx) in a directory or individual tactical graphics type mapping files. Can be used multiple times.
Merges all unit type mapping files (*.metx) in a directory or individual unit type mapping files. Can be used multiple times.
--modelPreloadFileName filename Specifies a file that has a list of models to preload.
(-n | --notifyLevel) notify_level Specifies the notification level for application messages. Range: 0-4.
--noAppDataEntityDefs Do not load the entity element definitions in ./appData/definitions.
--noAppDataTacticalGraphicsDefs Do not load the tactical graphics element definitions in ./appData/defini-
tions.
--noAppDataUnitDefs Do not load the unit element definitions in ./appData/definitions.
--noAppDataEntityTypeMap Do not load entity type mappings in ./appData/settings/<application>.
--noAppDataModelDefs Do not load model definitions in ./appData/definitions.
--noAppDataTacticalGraphicsTypeMap Do not load tactical graphics type mappings in ./appData/settings/<appli-
cation>.
--noAppDataEntityTypeMap Do not load unit type mappings in ./appData/settings/<application>.
--nonVrfObjectsUUIDScheme scheme Sets the UUID scheme for non VR-Forces objects. Values are entity-iden-
tifier, global-identifier, marking-text. Default: entity-identifier.
(-O | --hasNTPSync) Enables synchronized ocean between different display engines. System
clocks must be synchronized.
--plugin filename Load the specified plug-in. Can be used multiple times.
--pseudoFullScreen Use pseudo full screen for full screen mode.
--pvd Start the VR-Forces front-end with only 2D modes available.
(-S | --suppressHatIntersectOnAttach) Suppress the periodic HAT intersection when attached.
--scenarioFile filename Specifies a scenario to load.
--stealth Start the VR-Forces front-end with only 3D modes available.
--stencilBits bits Sets the number of stencil bits (0 or 8). Default: 0.
--tcpSendTimeout Sets the timeout (in seconds) for the master display engine to wait for a remote display engine before giving up on a send. Default: 30 seconds.
(terrain_MTF_file | scene_MSF_file) Specifies a terrain (MTF) or scene (MSF) file to load.
--unplug filename Do not load the specified plug-in. Can be used multiple times.
--useAbsoluteTimeStamps Use absolute time stamps instead of relative time stamps.
--useFileCommChannel channel The communication file to be used as a base for communicating text
based commands from external applications.
--userDataDir directory Specifies the user data directory.
(-v | --version) Display version information and exit.
(-z | --useReverseZBuffer) Specifies use of reverse Z-buffering, which can reduce Z-fighting.
(-Z | --ignoreZoomForSpeedtreeLod Disable zoom for SpeedTree LOD.
HLA Only
HLA Only
(-a | --appNumber) number Application number.
(-f | --fomMapperLib) libname FOM Mapper library name.
(-F | --fedFileName) fedfile_name FED file name.
--fomMapperInitData data FOM Mapper initialization data.
--fomModules module Specifies a FOM Module. Can be used multiple times. (HLA Evolved only.)
(-H | --hostAddressString) address Specifies the host address.
(-i | --sessionId) ID Specifies the session ID for this instance of the front-end.
(-N | --federateName) federate_name Federate name. Default: VR-Forces. (HLA Evolved only.)
(-p | --federateType) type The federate type distinguishes different categories of federates.
--rprFomRevision RPR FOM revision.
--rprFomVersion version_number RPR FOM version. (0.5, 0.7, 0.8, 1.0, 2.0006, 2.0014, 2.0017, or 2.0)
(-s | --siteId ID Site ID.
--localSettingsDesignator designator Specifies a string that is passed to the RTI during federate connect. (HLA
Evolved only.)
--ignoreAdvisories Enables or disables HLA advisory messages. Default: true.
--useGeographicDdm Specifies use of geographic DDM if you are using the MÄK RTI. Default: false.
(-x | --execName) exec_name Execution name. Default: VR-Link.
DIS Only
DIS Only
(-a | --appNumber) number Application number.
(-A | --destAddrString) address Destination address.
--defaultObjectTimeout timeout Specifies the timeout interval for objects.
--deviceAddress address Specifies the address of the network card to use for UDP traffic.
--disVersion The DIS version. Default: 5.
(-H | --hostAddressString) address Specifies the host address. This is usually the same as the device
address.
(-i | --sessionId) ID Specifies the session ID for this instance of the front-end.
--mcastTtl Specifies the multicast time-to-live. Default: -1.
--multicastAddresses address1 ... Specifies one or more multicast addresses.
addressn
(-P | --disPort) port DIS port.
--recvBufferSize size Receive buffer size.
(-s | --siteId ID Site ID.
--sendBufferSize size Send buffer size. Default: -1.
--subnetMask mask Specifies a subnet mask.
--useAsyncIO Use asynchronous I/O. Default: False.
--useIpv6 Use the ipv6 protocol, if available.
(-x | --exerciseId) ID Exercise ID.
Table QR-3: Mouse Button Mappings
Navigation Action | Mouse Action | Context |
Attach to entity. | Shift+left-click | Entity. |
Attach to prop. | Ctrl+Shift+left-click | Prop. |
Deselect all. | Left-click | Terrain or sky. |
Drag terrain. | Left-click+drag | Terrain or prop. |
Object selected, others unselected. | Left-click | Selected entity or prop. |
Select entity or prop. | Ctrl+left-click | Unselected entity or prop. |
Select object and unselect all others. | Left-click | Unselected entity or prop. |
Teleport to location. | Shift+left-click | Terrain. |
Teleport to prop. | Shift+left-click | Prop. |
Teleport to entity. | Ctrl+Shift+left-click | Entity. |
Unselect. | Ctrl+left-click | Selected entity or prop. |
Display context-sensitive menu. | Right-click | Entity or prop. |
3D Only | ||
Drag the view. | Middle mouse button drag | All. |
Drag heading and pitch (mouse look). | Right Drag | All. |
Orbit drag. | Ctrl+left-click+drag | Terrain or prop. |
Zoom in (magnification). | Ctrl+ mouse wheel forward | All. |
Zoom out (magnification). | Ctrl+ mouse wheel backward | All. |
Reset magnification. | Middle mouse button | All. |
Move observer forward. | Mouse wheel forward | All. |
Move observer back. | Mouse wheel back | All. |
Move observer level observer forward. | Shift+mouse wheel forward. | All. |
Move observer level observer back- ward. | Shift+mouse wheel backward. | All. |
Move flashlight beam. | Right mouse button drag | All. |
Expand flashlight beam. | Alt+mouse wheel forward. | All. |
Contract flashlight beam. | Alt+mouse wheel backward. | All. |
2D Only | ||
Rotate terrain. | Right-click + drag | All. Orient North disabled. |
2D Zoom in. | Mouse wheel forward; Middle button + drag | All. |
2D Zoom out. | Mouse wheel backward; Middle button + drag | All. |
K = numeric keypad (K8 means press Keypad 8). To use the numeric keypad for navigation, NumLock must be on.
Table QR-4: Observer Keyboard Mappings
Observer Movement | Observer | Level Observer | Laptop | 2D Level Observer |
Move forward. | w | unmapped | w | unmapped |
Move back. | s | unmapped | s | unmapped |
Move left. | a | unmapped | a | unmapped |
Move right. | d | unmapped | d | unmapped |
Move up. | q, Ctrl+q | unmapped | q, Ctrl+q | unmapped |
Move down. | e, Ctrl+e | unmapped | e, Ctrl+e | unmapped |
Move forward level observer. | unmapped | w | unmapped | w |
Move back level observer. | unmapped | s | unmapped | s |
Move left level observer. | unmapped | a | unmapped | a |
Move right level observer. | unmapped | d | unmapped | d |
Move up level observer. | unmapped | q, Ctrl+q | unmapped | unmapped |
Move down level observer. | unmapped | e, Ctrl+e | unmapped | unmapped |
Move attached context forward. | Shift+w | Shift+w | Shift+w | Shift+w |
Move attached context back. | Shift+s | Shift+s | Shift+s | Shift+s |
Move attached context left. | Shift+a | Shift+a | Shift+a | Shift+a |
Move attached context right. | Shift+d | Shift+d | Shift+d | Shift+d |
Move attached context up. | Shift+q | Shift+q | Shift+q | unmapped |
Move attached context down. | Shift+e | Shift+e | Shift+e | unmapped |
Level yaw left. | K 4 | K 4 | Left arrow | Left arrow |
Level yaw right. | K 6 | K 6 | Right arrow | Right arrow |
Level pitch up. | Shift+j | Shift+j | Shift+j | unmapped |
Level pitch down. | Shift+k | Shift+k | Shift+k | unmapped |
Level roll right. | Shift+i | Shift+i | Shift+i | unmapped |
Level roll left. | Shift+m | Shift+m | Shift+m | unmapped |
Yaw left. | Shift+h | Shift+h | Shift+h | Shift+h |
Yaw right. | Shift+l | Shift+l | Shift+l | Shift+l |
Pitch up. | K 8 | K 8 | | unmapped |
Pitch down. | K 2 | K 2 | | unmapped |
Roll right. | K 9 | K 9 | K 9 | unmapped |
Roll left. | K 3 | K 3 | K 3 | unmapped |
Orbit right. | Ctrl+d, | Ctrl+d, | Ctrl+d | unmapped |
Orbit left. | Ctrl+a, | Ctrl+a, | Ctrl+a | unmapped |
Orbit up. | Ctrl+w, | Ctrl+w, | Ctrl+w | unmapped |
Orbit down. | Ctrl+s, | Ctrl+s, | Ctrl+s | unmapped |
Look up. | Ctrl+K 8 | Ctrl+K 8 | Ctrl+K 8 | Ctrl+K 8 |
Look down. | Ctrl+K 2 | Ctrl+K 2 | Ctrl+K 2 | Ctrl+K 2 |
Look left. | Ctrl+K 4 | Ctrl+K 4 | Ctrl+K 4 | Ctrl+K 4 |
Table QR-4: Observer Keyboard Mappings | ||||
Observer Movement | Observer | Level Observer | Laptop | 2D Level Observer |
Look right. | Ctrl+K 6 | Ctrl+K 6 | Ctrl+K 6 | Ctrl+K 6 |
Look tilt left. | Ctrl+K 3 | Ctrl+K 3 | Ctrl+K 3 | Ctrl+K 3 |
Look tilt right. | Ctrl+K 9 | Ctrl+K 9 | Ctrl+K 9 | Ctrl+K 9 |
Zoom In | unmapped | unmapped | unmapped | Ctrl + e |
Zoom Out | unmapped | unmapped | unmapped | Ctrl + q |
Suppress constrain to terrain. | x | x | x | x |
Water Impact | unmapped | unmapped | unmapped | unmapped |
Reset observer: | Space | Space | Space | Space |
In absolute mode, go to the center of the scene. If attached, reset the attach position and orientation. | ||||
Toggle Speed Scaling Mode (MSL or AGL) | unmapped | unmapped | unmapped | unmapped |
Level observer. | K 5 | K 5 | Shift+Space+ | K 5 |
Toggle Force North Orientation | unmapped | unmapped | unmapped | unmapped |
Toggle Orient To Target Constraint | unmapped | unmapped | unmapped | unmapped |
Toggle Flashlight | F | F | F | F |
Reset the camera. | K 0 | K 0 | K 0 | |
Increase View Magnification | = | = | = | unmapped |
Decrease View Magnification | - | - | - | unmapped |
Reset View Magnification | 0 | 0 | 0 | unmapped |
Increase View Resolution | unmapped | unmapped | unmapped | = |
Decrease View Resolution | unmapped | unmapped | unmapped | - |
Detach. | z | z | z | z |
Toggle Hide Model On Attach | unmapped | unmapped | unmapped | unmapped |
Attach to the next entity allowed by the attachment filter. | Period (.) | Period (.) | Period (.) | Period (.) |
Attach to next entity or prop. | > | > | > | > |
Attach to the previous entity allowed by the attachment filter. | Comma (,) | Comma (,) | Comma (,) | Comma (,) |
Attach to previous entity or prop. | < | < | < | < |
Set Mimic Attach Type | unmapped | unmapped | unmapped | unmapped |
Set Tether Attach Type | unmapped | unmapped | unmapped | unmapped |
Next attach mode. | Shift+z | Shift+z | Shift+z | Shift+z |
Increase linear speed. | K 7 | K 7 | K 7 | K 7 |
Decrease linear speed. | K 1 | K 1 | K 1 | K 1 |
Increase orbit speed. | K + | K + | K + | K + |
Decrease orbit speed. | K - | K - | K - | K - |
Increment Rotation Speed Gain | unmapped | unmapped | unmapped | unmapped |
Table QR-4: Observer Keyboard Mappings | ||||
Observer Movement | Observer | Level Observer | Laptop | 2D Level Observer |
Look right. | Ctrl+K 6 | Ctrl+K 6 | Ctrl+K 6 | Ctrl+K 6 |
Look tilt left. | Ctrl+K 3 | Ctrl+K 3 | Ctrl+K 3 | Ctrl+K 3 |
Look tilt right. | Ctrl+K 9 | Ctrl+K 9 | Ctrl+K 9 | Ctrl+K 9 |
Zoom In | unmapped | unmapped | unmapped | Ctrl + e |
Zoom Out | unmapped | unmapped | unmapped | Ctrl + q |
Suppress constrain to terrain. | x | x | x | x |
Water Impact | unmapped | unmapped | unmapped | unmapped |
Reset observer: | Space | Space | Space | Space |
In absolute mode, go to the center of the scene. If attached, reset the attach position and orientation. | ||||
Toggle Speed Scaling Mode (MSL or AGL) | unmapped | unmapped | unmapped | unmapped |
Level observer. | K 5 | K 5 | Shift+Space+ | K 5 |
Toggle Force North Orientation | unmapped | unmapped | unmapped | unmapped |
Toggle Orient To Target Constraint | unmapped | unmapped | unmapped | unmapped |
Toggle Flashlight | F | F | F | F |
Reset the camera. | K 0 | K 0 | K 0 | |
Increase View Magnification | = | = | = | unmapped |
Decrease View Magnification | - | - | - | unmapped |
Reset View Magnification | 0 | 0 | 0 | unmapped |
Increase View Resolution | unmapped | unmapped | unmapped | = |
Decrease View Resolution | unmapped | unmapped | unmapped | - |
Detach. | z | z | z | z |
Toggle Hide Model On Attach | unmapped | unmapped | unmapped | unmapped |
Attach to the next entity allowed by the attachment filter. | Period (.) | Period (.) | Period (.) | Period (.) |
Attach to next entity or prop. | > | > | > | > |
Attach to the previous entity allowed by the attachment filter. | Comma (,) | Comma (,) | Comma (,) | Comma (,) |
Attach to previous entity or prop. | < | < | < | < |
Set Mimic Attach Type | unmapped | unmapped | unmapped | unmapped |
Set Tether Attach Type | unmapped | unmapped | unmapped | unmapped |
Next attach mode. | Shift+z | Shift+z | Shift+z | Shift+z |
Increase linear speed. | K 7 | K 7 | K 7 | K 7 |
Decrease linear speed. | K 1 | K 1 | K 1 | K 1 |
Increase orbit speed. | K + | K + | K + | K + |
Decrease orbit speed. | K - | K - | K - | K - |
Increment Rotation Speed Gain | unmapped | unmapped | unmapped | unmapped |
Table QR-4: Observer Keyboard Mappings
Observer Movement | Observer | Level Observer | Laptop | 2D Level Observer |
Decrement Rotation Speed Gain | unmapped | unmapped | unmapped | unmapped |
Toggle speed scaling on or off. | K * | K * | K * | K * |
Toggle Prop Transparency | T | T | T | T |
Toggle Terrain Scaling | unmapped | unmapped | unmapped | unmapped |
Increment Terrain Scale | unmapped | unmapped | unmapped | unmapped |
Decrement Terrain Scale | unmapped | unmapped | unmapped | unmapped |
Toggle Track Histories | unmapped | unmapped | unmapped | unmapped |
Toggle Entity Labels | L | L | L | L |
Toggle Rotate Entity Symbols | unmapped | unmapped | unmapped | unmapped |
Toggle Tactical Graphics | Shift+G | Shift+G | Shift+G | Shift+G |
Toggle Entity Height Above Terrain Lines | unmapped | unmapped | unmapped | unmapped |
Toggle Tactical Graphics HAT Lines | unmapped | unmapped | unmapped | unmapped |
Toggle Entity Height Above Terrain Mode | unmapped | unmapped | unmapped | unmapped |
Toggle Tactical Graphics Height Above Terrain Mode | unmapped | unmapped | unmapped | unmapped |
Toggle constrain to terrain on or off. | / | / | / | / |
Toggle Constrain To Center | U | unmapped | unmapped | unmapped |
Clear the current movement mode. This key is an escape mechanism if keys are not behaving as you expect. This is typi- cally due to a loss of the window context. | c | c | c | c |
Next Observer Mode | ] | ] | ] | ] |
Previous Observer Mode | [ | [ | [ | [ |
Toggle view controls on or off. | Shift+c | Shift+c | Shift+c | |
Clear All Trajectory Histories. | unmapped | unmapped | unmapped | unmapped |
Toggle OSG Framerate statistics | F2 | F2 | F2 | F2 |
Print OSG statistics | Shift+[ | Shift+[ | Shift+[ | Shift+[ |
vrfLauncher Command-Line Options
Option Description
Option Description
(-B | --backend) Start vrfLauncher for the back-end only.
B-- Following --, arguments after B-- are passed only to the back-end.
(-C | --config) Open the Simulation Connections Configuration tool.
-debug Following B-- or F--, appends a d to vrfGui or vrfSim to run the debug version. (Windows only.)
(-F | --frontend) Start vrfLauncher for the front-end only.
F-- Following --, arguments after F-- are passed only to the front-end.
(-h | --help) Displays help information in a console window.
--usePredefinedConnection
connection
Specify a connection name, such as DIS localhost, so that the vrfLauncher can launch without needing to display the Simulation Connections dialog box.
(-v | --version) Displays version information.
-- Pass all arguments after this to vrfGui and vrfSim, except per B-- or F--.
Link - Simulate - Visualize
VRF-4.5-1-170217
150 CAMBRIDGE PARK DRIVE, 3RD FLOOR CAMBRIDGE, MA 02140 617.876.8085 www.mak.com
